Suppose I have a window running a progra. As an example let us use Proccess
Moniitor. If I minimize the window without stopping the process, does it
continue to consume procesor cycles? In other words, is it still a load on
system resources?

On Mon, 25 Sep 2023 15:49:26 GMT, MajorLanGod wrote:
>
> Suppose I have a window running a progra. As an example let us use Proccess
> Moniitor. If I minimize the window without stopping the process, does it
> continue to consume procesor cycles? In other words, is it still a load on
> system resources?

Most likely the program continues working. Think of a
copy operation in Explorer, for instance: it doesn't
stop if you minimize the Explorer window(s).

That said, some utility programs are sensitive to being
minimized and go from full-active to simply waiting for
a keypress or other event to retrigger them. I think of
KeePass and its relatives, for instance.

--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Shikata ga nai...

MajorLanGod wrote:
> Suppose I have a window running a progra. As an example let us use Proccess
> Moniitor. If I minimize the window without stopping the process, does it
> continue to consume procesor cycles? In other words, is it still a load on
> system resources?

It'll certainly still be occupying RAM.
Look for yourself in Task Manager. And that will also show you CPU
usage, disk usage, and more.

Ed

MajorLanGod <lonelydad58@gmail.com> wrote:

> Suppose I have a window running a progra. As an example let us use
> Proccess Moniitor. If I minimize the window without stopping the
> process, does it continue to consume procesor cycles? In other words,
> is it still a load on system resources?

A process does not require a window to run. A window is needed only if
user interaction is provided or required. All services run without
windows, and why they can load whether you have logged into a Windows
account, or not; i.e., they load on Windows startup, before you login,
and before you have any GUI (deslktop) to interface with them yourself.

Go into Task Manager under the Details tab, and look at the Status
column. If a process is running, it is using CPU cycles. If it is
suspended (to save power) then no. In the Details tab, words are used
to identify process status. In the Processes tab (an overview), a green
leaf icon appears to the right of the process' "friendly" name. UWP
(Universal Windows Platform) "apps", like what are pre-installed or you
get from the MS Store, are always suspended when they are not being used
(no user interaction) to save power.

https://www.tutorialspoint.com/what-are-the-different-states-of-a-process

You can also the Task Manager to change priority, kill, and do other
changes to processes. I'm assuming you did not put Task Manager into
its compact view. If you did, click on the "More details" button to get
into details view mode.

You should get acquainted with the Task Manager. It does a lot, and is
a highly useful tool.

https://www.howtogeek.com/405806/windows-task-manager-the-complete-guide/

On 9/25/2023 11:49 AM, MajorLanGod wrote:
> Suppose I have a window running a progra. As an example let us use Proccess
> Moniitor. If I minimize the window without stopping the process, does it
> continue to consume procesor cycles? In other words, is it still a load on
> system resources?
>

When you take your hands off the keyboard and mouse, the system is idle
(no Word or Excel or Notepad in use), the system still sees 10,000 events
a second just from Registry polling.

The event type filtering in Process Monitor, prevents certain events
from appearing in the display. However, all the events are recorded
in RAM (until you run out of RAM or the event count hits 199,000,000).

When you save out the events, you can have all the events transferred
to a file as well.

The compute activity, of handling 10,000 events a second, is still
present. As others told you, Task Manager is your friend, and
shows the activity level. Task Manager is less useful, when the
CPU has an extreme number of cores (it needs some digits after
the decimal point).

A give away on my computer, is the sound of the fan :-)
A runaway on one core, ramps the fan. That does not happen
on all computers. Some computers are so low power, they
never even bother to turn the fan up.

Process Monitor, is kinda limited as a result, in the time domain.
I've debugged a Macrium backup with Process Monitor, but the PML
file for that was pretty large. And modern Process Monitor, the
"search speed" in the tool, is 50x slower than it used to be,
so some of the "utility" of ProcMon is gone now.

It has had added to it, network events. but the IP addresses
on reverse lookup, a lot of them are "Akamai" anonymized ones,
so you cannot get any indication of "what you're talking to".
Perhaps correlation with Wireshark would help, but then the
trace of Wireshark would be mixed in with the rest of the machine
activity.

ProcMon is a "very large haystack".

Paul

On Mon, 25 Sep 2023 18:24:03 +0100, Ed Cryer <ed@somewhere.in.the.uk>
wrote:

>MajorLanGod wrote:
>> Suppose I have a window running a progra. As an example let us use Proccess
>> Moniitor. If I minimize the window without stopping the process, does it
>> continue to consume procesor cycles? In other words, is it still a load on
>> system resources?
>
>It'll certainly still be occupying RAM.

Yes.

Does that mean it is still a load on system resources? Only if the
total amount of RAM you have is low and the minimized window's use of
RAM causes you to use more page file.

If you have sufficient RAM, no it's not.

>Look for yourself in Task Manager. And that will also show you CPU
>usage, disk usage, and more.
>
>Ed

VanguardLH <V@nguard.LH> wrote:

> MajorLanGod <lonelydad58@gmail.com> wrote:
>
>> Suppose I have a window running a progra. As an example let us use
>> Proccess Moniitor. If I minimize the window without stopping the
>> process, does it continue to consume procesor cycles? In other words,
>> is it still a load on system resources?
>
> A process does not require a window to run. A window is needed only if
> user interaction is provided or required. All services run without
> windows, and why they can load whether you have logged into a Windows
> account, or not; i.e., they load on Windows startup, before you login,
> and before you have any GUI (deslktop) to interface with them yourself.
>
> Go into Task Manager under the Details tab, and look at the Status
> column. If a process is running, it is using CPU cycles. If it is
> suspended (to save power) then no. In the Details tab, words are used
> to identify process status. In the Processes tab (an overview), a green
> leaf icon appears to the right of the process' "friendly" name. UWP
> (Universal Windows Platform) "apps", like what are pre-installed or you
> get from the MS Store, are always suspended when they are not being used
> (no user interaction) to save power.
>
> https://www.tutorialspoint.com/what-are-the-different-states-of-a-process
>
> You can also the Task Manager to change priority, kill, and do other
> changes to processes. I'm assuming you did not put Task Manager into
> its compact view. If you did, click on the "More details" button to get
> into details view mode.
>
> You should get acquainted with the Task Manager. It does a lot, and is
> a highly useful tool.
>
> https://www.howtogeek.com/405806/windows-task-manager-the-complete-guide/

Oops, looks like you're asking about just Process Monitor. Presumably
that's the one from SysInternals. Yes, minimizing its window keeps the
program running to record events. If it didn't when minimize, it would
be a defective monitor; i.e., it wouldn't be monitoring without a
window, and monitoring usually means you are monitoring OTHER programs.

Process Monitor watches all system events. There can be LOTS of those.
Even non-critical events get recorded. If you define a filter, like you
want to watch just events on opening, reading, and writing a particular
file, all other events are still recorded. The filter just affects what
you see, not what gets recorded.

Leaving Process Monitor opening for a long time will slow your computer.
Eventually the computer gets so slow that it looks like it is hung.
Process Monitor is not something you leave running all the time trying
to catch a rare-time event. You use it when you setup your computer to
hopefully generate the event to help you track down what caused it.

There's a toolbar button you can use to start/stop the event recording.
That will let you decide when to start recording, and when to stop. If
the captured log doesn't have what you want, there's a toolbar button to
clear the log (to regain performance of the computer).

Unless you start/stop the event logging, yep, Process Monitor keeps
chugging along doing what it was designed to do: record ALL events (not
just those defined in a filter which just affects the view of what you
want to see).

Ken Blake <Ken@invalid.news.com> wrote:

> On Mon, 25 Sep 2023 18:24:03 +0100, Ed Cryer <ed@somewhere.in.the.uk>
> wrote:
>
>>MajorLanGod wrote:
>>> Suppose I have a window running a progra. As an example let us use Proccess
>>> Moniitor. If I minimize the window without stopping the process, does it
>>> continue to consume procesor cycles? In other words, is it still a load on
>>> system resources?
>>
>>It'll certainly still be occupying RAM.
>
> Yes.
>
> Does that mean it is still a load on system resources? Only if the
> total amount of RAM you have is low and the minimized window's use of
> RAM causes you to use more page file.
>
> If you have sufficient RAM, no it's not.

SysInternals' Process Monitor captures the events into a log stored in
memory. The filters only affect what you see, but PM keeps recording
ALL events. Filtering is non-destructive: no data is lost when
filtering, so ALL data is kept in the log (until if and when you choose
to clear the log, or exit PM). Eventually you will run out of memory no
matter how much you have. That you have more memory just means it will
take longer for responsiveness to get impact for you to notice it, but
eventually the computer will crawl to a near-stop and become unusable.
There is no setting in PM as to how much maximum memory it will consume
for its log. PM is designed to run for a short time trying to capture
events that might be pertinent to you troubleshooting a problem.

Presumably PM keeps its log in memory to avoid confusing the file I/O
events from overwhelming those you are trying to monitor. If, say, you
wanted to watch file writes, PM writing to a file means it would show
its own file writes to its log file on a drive.

Run PM long enough, and with all events getting recorded, and the
computer can run out of memory. How much RAM would be far more than
needed for all processes (now running and in the future) and also
encompass PM's memory log is variable. PM can easily slow the computer
until there is no space left in RAM. There is no threshold setting as
to when the memory log gets dumped to a file. There is no threshold as
to when to discard old entries after some maximum number of entries has
been reached (*). It's useful, but it can also be detrimental.

(*) Well, you can set a limit. The default, and the maximum, is 199
million /events/. Not the size of the events, not their aggregate size,
but just the count of events. An event could be short in content, or it
can be long. So, you can save up to 199 million variably sized events
for when the log (in memory) gets trimmed. It's doubtful that you need
to keep that many events in PM's memory log, but that depends on how
long you run PM trying to capture some particular events (which you
should be defining filters to catch what you're trying to detect since
seeing all events is worthless). It only takes a minute for my computer
to generate a million events, and sifting through all that means you're
wasting far too much time looking at the wrong events. You need to
define filters on what you want to look at. In fact, when you start PM,
it opens a dialog asking you to define filters since no one wants nor
needs to see all events to troubleshoot a problem.

There is also the overhead of PM doing the event recording, so it
obviously has some impact on context switching and memory calls along
with some impact on the data bus. Except with a very slow computer, you
probably won't notice any impact on responsiveness of the computer --
until PM has eaten a huge part of your RAM.

When I run PM, and when it shows its dialog asking you to define
filters, CPU usage is zero. When I run PM (with or without filters), it
consumes very little CPU uses (under 1%, so usually it shows as 0% in
Task Manager). That depends on how fast your computer is generating
events. When PM writes to its window (whether visible or not) is when
CPU usage jumps to about 8%. If you don't use any filters, PM will
spend more time writing event entries to its window. However, in Task
Manager, watch how PM keeps consuming memory. After a couple minutes,
for me PM (procmon64.exe) has eaten up 22 MB of RAM. At the bottom of
PM's window is its status bar. You can see how many events have been
captured by PM. I've never waited long enough to watch PM get to its
199 million event threshold to start discarding old log entries to see
if memory consumption by PM gets capped.

Overall, PM will probably show 1%, or less, of CPU usage. That is
regardless of whether the window's visible attribute is on or off. That
a window is not visible does not stop writing to it. More importantly
is to watch how much PM consumes over time. 199 million events could
eat up too much of your RAM impacting its responsiveness. If you are
only interested in the events for which you defined filters, reduce the
count threshold setting in PM to reduce its memory footprint. Depends
how long it takes for the filter to find the event you defined it to
show, and how many and fast the events your computer is generating.

MajorLanGod wrote:
> Suppose I have a window running a progra. As an example let us use Proccess
> Moniitor. If I minimize the window without stopping the process, does it
> continue to consume procesor cycles? In other words, is it still a load on
> system resources?
>

Load is very broad term - and can be different for other users and
devices. Load may or may not be a constant burden on a device since
programs can be active, idle, etc.

Any program running with or without an open or minimized windows will
continue to use system resources. Not all resources in use will be a
*load* on the system.
-> The impact depends on the system(CPU, RAM, Page file) and in some
cases how the program code interacts with Windows.

For the most part a program coded correctly/compatible with/for the
operating system when sufficient horsepower(CPU), RAM, paging) is
available may not be undesirable 'load'.

Process Monitor will always use some resources but normally not enough
to throttle general use.

--
....w¡ñ§±¤ñ

On 9/25/2023 3:33 PM, VanguardLH wrote:
> Ken Blake <Ken@invalid.news.com> wrote:
>
>> On Mon, 25 Sep 2023 18:24:03 +0100, Ed Cryer <ed@somewhere.in.the.uk>
>> wrote:
>>
>>> MajorLanGod wrote:
>>>> Suppose I have a window running a progra. As an example let us use Proccess
>>>> Moniitor. If I minimize the window without stopping the process, does it
>>>> continue to consume procesor cycles? In other words, is it still a load on
>>>> system resources?
>>>
>>> It'll certainly still be occupying RAM.
>>
>> Yes.
>>
>> Does that mean it is still a load on system resources? Only if the
>> total amount of RAM you have is low and the minimized window's use of
>> RAM causes you to use more page file.
>>
>> If you have sufficient RAM, no it's not.
>
> SysInternals' Process Monitor captures the events into a log stored in
> memory. The filters only affect what you see, but PM keeps recording
> ALL events.

You can set the log storage to disk if you want. That will require
restarting the tool once, for it to "take" and be the current mode of operation.

Using RAM for this, reduces the impact on the storage subsystem.
Like, if you were using a hard drive partition to store the events,
that would slow down your session somewhat.

However, for the following section, there may be some profit in using
the hard drive option, as doing so allows capturing a Shutdown trace.

*******

There is also a mode of Process Monitor, that allows recording shutdown
and startup of the PC. To capture shutdown, you set the event recording
to go to disk. When the computer shuts down, the event file will be closed,
just before the file system is dismounted.

When the computer awakes, an injected DLL hidden from view in System32,
starts recording events of the startup. If you start up the ProcMon.exe
executable two minutes later, it will prompt you to do something with the trace
it is capturing. It will also prompt you, concerning the shutdown trace.
In this way, after you wait two minutes after startup, you can save
BOTH files. And review at your leisure.

The injected DLL might be ProcMon23.dll or ProcMon24.dll . The version
number gets bumped, any time the program is updated in a significant way.
For example, the addition of networking events, may cause that DLL to
get bumped. The DLL does not get removed when you aren't using it. Since
it has Hidden set on it, you might not see it without a dir /ah or similar.
I only mention this in cases where that is malfunctioning for some reason,
and you are unable to collect a startup trace (it happens). Knowing what
the agent is, you can work on kicking it to the curb.

There are other tools for this (Microsoft written), which allow
selecting which event types to record during Startup, and that comes with a
fancier graphical output.

But for some users, the notion of one-stop-shopping and less screwing around,
makes this an attractive option.

Paul

On 9/25/2023 3:54 PM, ...winston wrote:
> MajorLanGod wrote:
>> Suppose I have a window running a progra. As an example let us use Proccess
>> Moniitor. If I minimize the window without stopping the process, does it
>> continue to consume procesor cycles? In other words, is it still a load on
>> system resources?
>>
>
> Load is very broad term - and can be different for other users and devices.  Load may or may not be a constant burden on a device since programs can be active, idle, etc.
>
> Any program running with or without an open or minimized windows will continue to use system resources. Not all resources in use will be a *load* on the system.
>  -> The impact depends on the system(CPU, RAM, Page file) and in some cases how the program code interacts with Windows.
>
> For the most part a program coded correctly/compatible with/for the operating system when sufficient horsepower(CPU), RAM, paging) is available may not be undesirable 'load'.
>
> Process Monitor will always use some resources but normally not enough to throttle general use.
>
>

Process Explorer, if launched as Administrator, has a few nice functions for monitoring.

It can show you "how many ticks" a program used. For programs waiting for an external
event to show up ("blocked"), the program may use zero ticks. And in that state
(because it is not polling for the event), no cycles are used.

You can check SVCHOSTs this way, and notice that a lot of them
are using zero ticks (so not wasting electricity). SVCHOSTs mainly
waste RAM (and don't use much), but aren't wasting electricity.

In the picture here, SuperPI, a greedy program, keeps a single core
busy. And we can measure it in various ways.

[Picture]

https://i.postimg.cc/XYGJCKSY/View-Super-PI-in-Process-Explorer.gif

My processor has a nominal clock of 3.4GHz. And the Process Explorer
developer, seems to be using RDTSC or similar, scaling by nominal
clock, and using that as a "cycle" definition. Whereas the actual
processor (as measured by the AMD company), records that a single
core is running at 5GHz. And they are likely taking the multiplier
(50x) and the nominal bus clock (100MHz) to get the number. Since
the bus clock (BCLK) may wander a bit, the numbers won't be nice round ones.
MSI may have set BCLK to 101MHz, times 50x, to get 5044 (close to 5050).

Paul

Paul <nospam@needed.invalid> wrote:

> VanguardLH wrote:
>
>> SysInternals' Process Monitor captures the events into a log stored
>> in memory. The filters only affect what you see, but PM keeps
>> recording ALL events.
>
> You can set the log storage to disk if you want. That will require
> restarting the tool once, for it to "take" and be the current mode of operation.

I just noticed the File -> Backing Files menu, but that is already using
a file on disk: virtual memory (pagefile). However, the program isn't
doing the file writes. The OS does that for the pagefile/RAM
management, and writes are in blocks, not bytes. I do see you can
specify a target file instead. Hmm, wonder what would be the impact on
the data bus along with which additional filters you would have to
define to hide the file I/O by ProcMon to the disk file. Obviously
writes to memory, even with pagefile as the backing store, are much
faster than writes to a disk file; however, it might workaround the RAM
consumption that slowly impacts system performance due to an evergrowing
RAM footprint. However, again, you end up consuming disk space for the
logfile dumped into a file.

Also, Windows events are not going to wait for Procmon to finish its
disk writes to record an event. Events can come fast and furious, and
they're getting generated at a high volume (remember even the
non-critical events are still getting recorded). Seems ProcMon could
get behind on recording events to a file meaning some events got missed.

I've never had to leave ProcMon running so long that I needed 199
million events to filter through trying to track down a problem. The
only time I ran into its RAM consumption was when I forgot to exit it.
I don't know what is the average size for an event to know what to
mulitple by 199 million to figure out how big would be the file log.
There's the description, event ID, and other info. Just guessing, but
say the item size is just 256 bytes in size. 199 million entries times
256 bytes is 50 gibabytes. I setup my hosts with LOTS of disk space: 1
TB for NVMe m.2 drive (C:), and SSD drives (with fast write speed) to
SATA3 headers on the mobo. However, lots of folks don't plan for nor
maintain a lot of free space on their internal drives. Nowadays 50 GiB
of disk space isn't critical, but it is for some.

> However, for the following section, there may be some profit in using
> the hard drive option, as doing so allows capturing a Shutdown trace.
>
> *******
>
> There is also a mode of Process Monitor, that allows recording shutdown
> and startup of the PC. ...
>
> When the computer awakes, an injected DLL hidden from view in System32,
> starts recording events of the startup. ...

Geez, DLL injection hasn't been banned yet? It has lots of legitimate
uses, but malware loves that infection vector. Along with deprecating
and eventually removing SetWindowHookEx(), I thought Microsoft was
working on removing code injection altogether. Android and iOS don't
allow it, but lots of software expects the scheme under Windows for them
to function. Windows would have to get dumbed down to be more secure.

Paul wrote:
> On 9/25/2023 3:54 PM, ...winston wrote:
>> MajorLanGod wrote:
>>> Suppose I have a window running a progra. As an example let us use Proccess
>>> Moniitor. If I minimize the window without stopping the process, does it
>>> continue to consume procesor cycles? In other words, is it still a load on
>>> system resources?
>>>
>>
>> Load is very broad term - and can be different for other users and devices.  Load may or may not be a constant burden on a device since programs can be active, idle, etc.
>>
>> Any program running with or without an open or minimized windows will continue to use system resources. Not all resources in use will be a *load* on the system.
>>  -> The impact depends on the system(CPU, RAM, Page file) and in some cases how the program code interacts with Windows.
>>
>> For the most part a program coded correctly/compatible with/for the operating system when sufficient horsepower(CPU), RAM, paging) is available may not be undesirable 'load'.
>>
>> Process Monitor will always use some resources but normally not enough to throttle general use.
>>
>>
>
> Process Explorer, if launched as Administrator, has a few nice functions for monitoring.
>
> It can show you "how many ticks" a program used. For programs waiting for an external
> event to show up ("blocked"), the program may use zero ticks. And in that state
> (because it is not polling for the event), no cycles are used.
>
> You can check SVCHOSTs this way, and notice that a lot of them
> are using zero ticks (so not wasting electricity). SVCHOSTs mainly
> waste RAM (and don't use much), but aren't wasting electricity.
>
> In the picture here, SuperPI, a greedy program, keeps a single core
> busy. And we can measure it in various ways.
>
> [Picture]
>
> https://i.postimg.cc/XYGJCKSY/View-Super-PI-in-Process-Explorer.gif
>
> My processor has a nominal clock of 3.4GHz. And the Process Explorer
> developer, seems to be using RDTSC or similar, scaling by nominal
> clock, and using that as a "cycle" definition. Whereas the actual
> processor (as measured by the AMD company), records that a single
> core is running at 5GHz. And they are likely taking the multiplier
> (50x) and the nominal bus clock (100MHz) to get the number. Since
> the bus clock (BCLK) may wander a bit, the numbers won't be nice round ones.
> MSI may have set BCLK to 101MHz, times 50x, to get 5044 (close to 5050).
>
> Paul
>

Process Explorer, on this device(i7-4770 CPU 3.4 GHz; 16 GB RAM) reports
Process Monitor using 0.19-0.46 CPU, ~18000 private bytes, ~37000
working set.
Load wise -> Marginal impact on resources

Also running/opened at the same time as PE and PM on Win10 22H2 - Edge,
Chrome, SeaMonkey, M365 Family Outlook, OneDrive, Windows Explorer, and
iTunes 12.12.
Task Manager reports CPU(ranging from 1-6%, occasional spike to 23%),
RAM 4.2 GB used, GPU 1%.

--
....w¡ñ§±¤ñ

On 9/26/2023 2:21 PM, VanguardLH wrote:
> Paul <nospam@needed.invalid> wrote:
>
>> VanguardLH wrote:
>>
>>> SysInternals' Process Monitor captures the events into a log stored
>>> in memory. The filters only affect what you see, but PM keeps
>>> recording ALL events.
>>
>> You can set the log storage to disk if you want. That will require
>> restarting the tool once, for it to "take" and be the current mode of operation.
>
> I just noticed the File -> Backing Files menu, but that is already using
> a file on disk: virtual memory (pagefile). However, the program isn't
> doing the file writes. The OS does that for the pagefile/RAM
> management, and writes are in blocks, not bytes. I do see you can
> specify a target file instead. Hmm, wonder what would be the impact on
> the data bus along with which additional filters you would have to
> define to hide the file I/O by ProcMon to the disk file. Obviously
> writes to memory, even with pagefile as the backing store, are much
> faster than writes to a disk file; however, it might workaround the RAM
> consumption that slowly impacts system performance due to an evergrowing
> RAM footprint. However, again, you end up consuming disk space for the
> logfile dumped into a file.
>
> Also, Windows events are not going to wait for Procmon to finish its
> disk writes to record an event. Events can come fast and furious, and
> they're getting generated at a high volume (remember even the
> non-critical events are still getting recorded). Seems ProcMon could
> get behind on recording events to a file meaning some events got missed.
>
> I've never had to leave ProcMon running so long that I needed 199
> million events to filter through trying to track down a problem. The
> only time I ran into its RAM consumption was when I forgot to exit it.
> I don't know what is the average size for an event to know what to
> mulitple by 199 million to figure out how big would be the file log.
> There's the description, event ID, and other info. Just guessing, but
> say the item size is just 256 bytes in size. 199 million entries times
> 256 bytes is 50 gibabytes. I setup my hosts with LOTS of disk space: 1
> TB for NVMe m.2 drive (C:), and SSD drives (with fast write speed) to
> SATA3 headers on the mobo. However, lots of folks don't plan for nor
> maintain a lot of free space on their internal drives. Nowadays 50 GiB
> of disk space isn't critical, but it is for some.
>
>> However, for the following section, there may be some profit in using
>> the hard drive option, as doing so allows capturing a Shutdown trace.
>>
>> *******
>>
>> There is also a mode of Process Monitor, that allows recording shutdown
>> and startup of the PC. ...
>>
>> When the computer awakes, an injected DLL hidden from view in System32,
>> starts recording events of the startup. ...
>
> Geez, DLL injection hasn't been banned yet? It has lots of legitimate
> uses, but malware loves that infection vector. Along with deprecating
> and eventually removing SetWindowHookEx(), I thought Microsoft was
> working on removing code injection altogether. Android and iOS don't
> allow it, but lots of software expects the scheme under Windows for them
> to function. Windows would have to get dumbed down to be more secure.
>

I tested ProcMon, by setting a backing file on my RAMDrive,
and the I/O slows down after the trace starts.

It was writing at 21MB/sec for a few seconds, but eventually
(with little going on), the write rate dropped to low kilobytes.
This suggests some sort of dedup and only unique events are
being recorded with brand new records.

If I attempt to set the display filter to "ProcMon.exe" and "WriteFile",
nothing shows in the trace, so it conveniently removes itself automatically
from the trace. Even though it throws "Excludes" for ProcMon in the
filter, if I remove that filter item and add an "Includes" for ProcMon,
you still can't see any WriteFiles recorded against it.

ProcMon is not a debugger, and does not collect an instruction trace.
The events, smell of "kernel calls" kinds of events. If you do a WriteFile,
that is a kernel call. If the kernel is doing the recording, then the
kernel can block while it handles anything it chooses, and then the
speed of the machine, is "whatever is left". The programs do not slow
down. If a program is CPU bound and is not calling the kernel, then
it still runs at the full speed. However, if it calls the kernel, it
has to wait for service and there could be an eventual penalty for that
(reduction in speed). When using the other Microsoft-written ETW recorders,
there is a warning in the documentation that if you include too many
event types, it can have an impact on what you're doing.

I:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xbootmgr.exe
I:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe

xbootmgr -trace boot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\TEMP

The other program is WPR (Windows Performance Recorder). WPA reboots the OS
multiple times and takes about two hours to collect traces and stuff, and this
is not particularly of value to an end user. But WPR might give you something
similar to xbootmgr.

BootVis back in WinXP era, was also pretty good at its job, but these later
things are more of an acquired taste.

Paul

Paul <nospam@needed.invalid> wrote:

> I tested ProcMon, by setting a backing file on my RAMDrive,
> and the I/O slows down after the trace starts.
>
> It was writing at 21MB/sec for a few seconds, but eventually
> (with little going on), the write rate dropped to low kilobytes.
> This suggests some sort of dedup and only unique events are
> being recorded with brand new records.
>
> If I attempt to set the display filter to "ProcMon.exe" and "WriteFile",
> nothing shows in the trace, so it conveniently removes itself automatically
> from the trace. Even though it throws "Excludes" for ProcMon in the
> filter, if I remove that filter item and add an "Includes" for ProcMon,
> you still can't see any WriteFiles recorded against it.

But filtering does not remove events from the log. It merely hides them
from view. If you remove the filter, all the viewed events are still
listed, but you'll then see all the events you hid using the filters.
Say I filter to only show events for firefox.exe. I'll see those in the
list, but the moment I delete those filters then everything shows up.