System process (PID 4) constantly accessing the hard disk

Solution 1:

This is an older question, but I had this issue, and for me it was SuperFetch. I tried everything I could find on PID 4 excessive hard drive usage, and some of it helped. A RAM upgrade from 4GB to 8GB only made the issue more obvious - RAM usage was low, no paging, but yet the hard drive was lit up for ~10 minutes after my laptop booted.

Long story short, there's a registry setting that controls what level of SuperFetch is appropriate. You can see below the EnableSuperfetch value is now set to 1, which seems to be "prefetch all executables and libraries". The default is a 3, which seems to mean "prefetch all executables, libraries, and documents". I have many documents, so I think this was taking way too long. Every document opened is another one that SuperFetch has to "analyze" to see how you're using it.

The registry key/value in question is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnableSuperfetch

So far the only downside is that my outlook folders take a few extra seconds to open, and some commonly used documents like MS Project files take longer. But those delays pale in comparison to the disk thrash I was getting before!

Solution 2:

A lot of system services (I don't mean Windows Services) run under PID 4, the "System" process. Every time you open a file, you trigger a slew of background mechanisms such as the virtual memory manager caching the file in memory, moving other things around in memory, servicing page faults, etc. That activity is separate from the disk activity charged against the process that originally accessed the file, e.g. WinRAR.

That said, what you're describing still doesn't sound like normal behavior to me. You should see a quick bump in disk activity from the System process when the file is accessed, and then it should go back to 0 rather quickly - within a couple seconds.

I did a little testing on my own machine using Windows Resource Monitor, and I saw somewhat similar behavior. What I think we're witnessing is Resource Monitor showing us some sort of rolling average that is slow to drop off.

Try looking at PID 4 disk activity using another tool such as Sysintenals' Process Explorer. I got a much different impression from it, as the Read Delta and Read Bytes Delta by the System process seem to return to 0 much faster than when viewed through ResMon.

Edit: If that's not it, then I think a more in-depth analysis is going to be needed in order to answer the question. For instance, you can list the currently-loaded file system filter drivers with fltmc.exe, and kernrate.exe can help you isolate those modules which are causing inordinately high disk I/O.