pyotr filipivich wrote:

VanguardLH:

pyotr filipivich wrote:

I have taken to running Process Monitor with the processes sorted by
CPU usage, so that I can "quickly" suspend msinfo32exe when it grabs
"half" the cpu and freezes everything else. Usually I notice this
when PaleMoon is running and suddenly the mouse pointer just stops.

Then begins the move mouse on the desk and aim for the procmon window,
then try to get the pointer on msinfo32 and then suspending/
terminating it is "simple".

Googleing it leads me to the conclusion that MS seems to believe I
really do want to run it, when what I want to know is why is it
running in the first place? Why is it running up to eight copies,
and why is it hogging resources so much?

Does anyone have any good ideas on how to prevent this, or is this
another MS "enhancement to my computer experience" whether I like it
or not?

Did you leave logging on and on and on and ... All those events are
getting logged while ProcMon is running. Filtering only changes
what you see. ALL events are still logged. When that logfile gets
huge, not only does it require lots of resources to keep updating
such a huge file but can also eat up your free disk space with a
huge log file. Did you try clearing its logfile to start anew each
time you start ProcMon?

I don't have ProcMon logging anything.

As soon as you enable it capturing events, yep, it is LOGGING. The
default when loading ProcMon (and after defining any filters) is to
start capturing. Even if you disable capture in a session of ProcMon
and clear its log, capture is enabled by default in the next session you
start when loading ProcMon. That's why you can see past events that it
logged. That's why you can define filters to change the *view* of what
you see in the log (not what gets added to the log -- which is
EVERYTHING gets put into the log). If you don't enable capture mode
then you won't see any new events so there is little use (just past past
events, not new events) for ProcMon.

And msinfo32 will start up before I start Procmon.

What's the point of leaving msinfo32 loaded if it will never change
anything it listed from the prior scan? You can load it, look at its
scan results, maybe save it, and then exit. Or you can load msinfo32,
look at what it scanned now, and then later do a refresh to see if there
were any changes.

I don't see a setting in msinfo32 that has it re-poll for hardware
changes at some periodic interval. If ProcMon is showing event from the
msinfo32.exe process then that program is [still] scanning. On my
computer, the scanning is done within a second of loading msinfo32
(versus Piriform's Speccy that takes much longer to do a scan). If
msinfo32.exe is sucking up half the CPU usage then it is scanning (the
first one it does when loaded or by having it do a refresh).

What happens
is all of a sudden the computer drops to a crawl, the mouse pointer
doesn't move, if I am patient, I'll work it over to a short cut, start
it, wait for it, work the pointer to the column CPU, sort by usage,
and work it down to msinfo32, and evenutal I'm able to suspend. (If I
am not patient, I use the BRS interupt to reboot)

Either the problem is with msinfo32 (which should not be sucking up lots
of CPU time because its scan should be quick) or because you have a huge
logfile in ProcMon which is choking the data bus on your mobo between
your memory and CPU and storage media.

Which still leaves me with this annoying problem that msinfo32 is
starting up just to start up and interfere with my computer experience
- whether I had procmonitor running or not. At least with procmonitor
running, I cut out several steps where I'm moving and clicking hoping
I found the shortcut when the mouse gets polled.

msinfo32 doesn't "just start up". YOU load it manually, as a startup
program you added to your Startup folder (or the All Users one), as a
scheduled event, or by some other means msinfo32.exe because a startup
program. If you don't want it to load on logging into Windows, try
using msconfig.exe to see if it is listed as a Startup Item. If it is
not listed there, use SysInternals' AutoRuns to check more startup
locations (in the file system or in the registry).