I'm using Windows 8 Pro x64. I've noticed that
Rundll32.exe process is taking a lot of CPU (25%, which is a 100% load of a single core) then I'm not not using computer, specifically then sceensaver is active. And that process is terminated immediately then screensaver goes away (then I move mouse, or press a key on keyboard).
I've found this because I'm using custom process monitoring program, that also allowed me to collect info about process (that is last info awailable from already stopped process):
Path = C:\WINDOWS\system32\rundll32.exe User Name = NT AUTHORITY \ SYSTEM PID/Parent PID = 4576 / 800 Started by = C:\WINDOWS\system32\services.exe Virtual KB Curr = 149 872 Peak = 299 416 Working Set KB Curr = 54 732 Peak = 54 732 Page File KB Curr = 46 720 Peak = 46 720 System Pool KB Paged = 208 Nonpaged = 22 Private KB = 46 720 Handles Count = 385 Faults Count = 293 958 Windows = 0 Reads = 4 255 Read KB = 56 263 Writes = 1 Write KB = 0 Other IOs = 677 511 Other KB = 8 614
From that info it's obvious that process is taking a lot of reads and no writes. Also it's started by Services Control Manager. I've never noticed such behaviour on my Windows 7 prior to upgrade, and wondering if it some sort of a bug which causing , or a some legitimate system scan task?
I'm using a
Blank screen screensaver, which is not using any CPU. I've actually verified that
scrnsave.scr is also terminated, but does not consume CPU. CPU is consumed specifically by
Rundll32.exe which is, obviously, somehow tied with screensaver DOWN events.
Also I've noticed that it start not exactly then ssaver starts, but some time after it (or maybe it have some other time interval of inactivity before it starts), but stops always then ssaver is stopped. And as I discovered it actually terminates after some time, I estimate latest encounter as about 2 minutes of work (but I'm not sure if it always takes this much time).
And (as I discovered just now) it seems it does not start again after finishing it's work. Looks like it is actually some legitimate system stuff is just going on, then system is idle. It makes sense since it takes a lot of CPU, so it won't slow down any user process (somewhat similarly to how
ngen.exe is working).