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?
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?
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?
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
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?
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 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.
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?
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.
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.
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.
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. ...
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 297 |
Nodes: | 16 (2 / 14) |
Uptime: | 07:23:55 |
Calls: | 6,666 |
Files: | 12,213 |
Messages: | 5,336,116 |