1

Every once in a while (I can't pin down exactly when, but it seems to be correlated with when the computer is idle for a while), the System process on my Windows 8.1 x64 machine suddenly starts using 100% of Core 1 of my CPU (8-core, so 12.5% of total CPU time).
To fix it, I usually just reboot (the laptop fan noise is annoying) -- although I recently noticed it seems to automatically calm down after 5-10 mins of activity.

I've tried to find the culprit using Process Hacker, and it seems to be the function MmTrimAllSystemPagableMemory as shown in the image below.

I don't remember if this happened on Windows 8.0, but this has never happened to me before, when I've had Windows 7 or earlier. So I'm confused what has changed, because this is a pretty old function.

What might be causing this? Is there some way for me to prevent it?

For what it's worth, it seems this is related somehow to a Task (ResolutionHost?) and relevant APIs include MmScrubMemory and CMemoryDiagnosticHandler:

user541686
  • 23,663
  • 46
  • 140
  • 214
  • 1
    Why the downvote? – user541686 Dec 20 '13 at 03:25
  • do you use an older VMware version which is not 8.x compatible? Also provide a xperf trace: http://pastebin.com/pgE11HRD – magicandre1981 Dec 20 '13 at 05:17
  • @magicandre1981: I don't use VMware at all. Thanks for the link, I'll try it the next time it happens (I'm not sure how to reproduce it myself). – user541686 Dec 20 '13 at 05:39
  • btw, use this command: http://pastebin.com/4h2ySm1V It also captures some memory data. – magicandre1981 Dec 20 '13 at 18:23
  • @magicandre1981: It just happened again, but when I tried xperf I got `xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7).` – user541686 Jan 02 '14 at 20:50
  • this error happens when you run a program which already uses ETW (ProcExp, ResMon, Taskmgr). Close them before running xperf. – magicandre1981 Jan 03 '14 at 07:23
  • @magicandre1981: Ohh I see thanks, I'll try it again when it happens. – user541686 Jan 03 '14 at 07:38
  • Is there any specific reason as to why you believe MmTrimAllSystemPagableMemory is the culprit? It's in the middle of the call stack, and judging from the function name it is simply a memory maintenance function unlikely to be the root cause. – Zero3 Jan 25 '14 at 17:49
  • @Zero3: Yeah, because it's something that seems to get triggered by idleness (which correlates with the function name) and because I can't find any other reason. If you know of a different reason though let me know, this is just my best guess. – user541686 Jan 25 '14 at 20:21
  • @Mehrdad: I can't quite see the connection between idleness and the MmTrimAllSystemPagableMemory function name in the middle of the call stack. Care to explain? I would personally look at the root: keSynchronizEexecution. Windows Internals (the book) seems to suggest that this function relies on a spinlock internally (explaining the CPU usage) and is commonly used by IO device drivers. So my guess would be that you have some IO activity (disk, network, other device?) going on and that the relevant driver *may* contain some rather poor synchronization logic, or is quite simply just busy. – Zero3 Jan 26 '14 at 09:01
  • @Zero3: A relevant driver? There is no relevant driver! That's the *entire* call stack, there's no driver code there! As for idleness, I'm just saying that this only seems to happen when my computer is idle, that's all. i.e. it doesn't seem to happen when the computer is not idle. Trimming memory pages is also a low-priority task, so it makes sense for that to happen when the system is idle. I don't have much else to explain about it... – user541686 Jan 26 '14 at 09:05
  • @Mehrdad The entire call stack of that specific thread, yes. Since the call stack doesn't show the origin of the thread, I merely pointed out that this function commonly is used by device drivers (and may or may not also be used by the kernel itself). I don't see any indication in the provided screenshot that this is *not* caused by device drivers, so it seems like a plausible cause given the documentation of the function. Regarding idleness: Windows (and programs) may do many things while the computer is idle (defragging, indexing, ...), often stopping once the user resumes work. – Zero3 Jan 26 '14 at 09:22
  • @Mehrdad If you are referring to the thread priority, then it certainly doesn't mean that the "task" (thread) will be deferred until the system is idle. The execution of such threads will be interleaved with higher priority threads to avoid starvation, albeit given less CPU time. – Zero3 Jan 26 '14 at 09:26
  • @Zero3: I'm a little confused, why do you think a *driver* would queue `MmTrimAllSystemPagableMemory` to be called on a separate thread? As for idleness, yes I'm aware idle priority doesn't require computer idleness, but there's still a correlation and frankly I didn't have a better explanation. If you have any ideas on what might be causing this (and I should point out that **this has happened on more than one computer**) by all means, I'd love to hear it. – user541686 Jan 26 '14 at 09:32
  • @Mehrdad I don't think so. MmTrimAllSystemPagableMemory was called by other functions in the call stack, as seen in your screenshot. As to why some other thread/process spawned the keSynchronizEexecution thread, I can only guess. My first shot would still be to look into whether the computers are doing any IO work when this issue presents itself. The task manager in Windows 8 should be able to show both disk and network activity, which could be a place to start :). – Zero3 Jan 26 '14 at 09:52
  • @Zero3: As far as I've been able to tell, the system is otherwise idle (no I/O, no network, nothing)... I'll let you know if it happens again and I observe otherwise, but I'm pretty sure nothing else is happening. – user541686 Jan 26 '14 at 10:33
  • @magicandre1981: I got a trace, but it says it may contain personal info. Also it's 100 MB. Any tips on how to share it keeping these two in mind? – user541686 Feb 06 '14 at 02:46
  • @magicandre1981: [Here's a screenshot, does this help?](http://i.imgur.com/tbf3HvU.png) – user541686 Feb 06 '14 at 02:56
  • the cause is *RtlScrubMemory*. But I have no idea why you see this. I think you should call the Microsoft Support about it and give them the ETL file. – magicandre1981 Feb 06 '14 at 05:00

1 Answers1

1

ok, because I saw the RtlScrubMemory issue several time I asked Microsoft about it. This functions is used to test the installed RAM.

Look if the idle Maintenance kicks up (look into the process graph) and tries to optimize Windows. if yes, disable the Idle Maintenance task in task scheduler to get rid of it.

Community
  • 1
magicandre1981
  • 97,301
  • 30
  • 179
  • 245
  • +1 thank you for posting this. How did you ask about it if you don't mind me asking -- online on some support page, or did you know an employee? – user541686 Jun 07 '14 at 07:40
  • I've asked this directly a MS employee – magicandre1981 Jun 07 '14 at 16:23
  • Seems like this isn't the exact issue, because my SYSTEM process is currently utilizing an entire CPU but the Idle and Regular Maintenance tasks both say the task isn't running -- and that the "last run result" was "The process terminated unexpectedly." (0x8007042B). – user541686 Jul 19 '14 at 21:22
  • 1
    In fact it looks like the explanation you got is completely bogus, because I just ran that task on demand (after some trickery to make it possible) and those tasks just spawned a bunch of new processes like NGEN, Windows Defender, etc... but the SYSTEM process was unaffected. So those tasks are actually irrelevant. – user541686 Jul 19 '14 at 21:33