Windows – Where did the “compressed memory” go

Analyzing the ETL file with WPA shows, that the CPU usage doesn't come from system memory compression. It comes from ntoskrnl.exe!MiScrubMemoryWorker:

Line #, DPC/ISR, Process, Stack Tag, Stack, Count, TimeStamp (s), % Weight
8, , , ,    |    |    |- ntoskrnl.exe!MiScrubMemoryWorker, 79667, , 12,45
9, , , ,    |    |    |    ntoskrnl.exe!MiScrubNode, 79667, , 12,45
10, , , ,   |    |    |    ntoskrnl.exe!MiScrubNodeLargePages, 79667, , 12,45
11, , , ,   |    |    |    ntoskrnl.exe!MiScrubNodeLargePageList, 79667, , 12,45
12, , , ,   |    |    |    |- ntoskrnl.exe!MiScrubPage, 79663, , 12,45
13, , , ,   |    |    |    |    |- ntoskrnl.exe!RtlScrubMemory, 79653, , 12,45
14, , , ,   |    |    |    |    |    |- ntoskrnl.exe!RtlpGenericRandomPatternWorker, 38549, , 6,02

This is a function to test the memory for errors by filling / reading some patterns (ntoskrnl.exe!RtlpGenericRandomPatternWorker).

This is by design and happens when the idle maintenance task kicks up when your device is idle.

You can try adding more memory pressure to your system such that Windows pushes memory pages from RAM to the page file. The sysinternals testlimit program lets you allocate lots of memory (as outlined in one of Russinovich's blog posts), which should (hopefully) convince the memory manager to push data to the page file.

Run the following and let it hammer for a while (monitor your RAM in task manager), then terminate it.

testlimit64 -m 100

You should see other processes physical commit charge (ie: actual RAM usage) decrease and testlimit hog everything. When testlimit ends, you should have more RAM available than when you started.

Important note: this may let you start your VM, but will also slow down all the other programs running on your computer because when you next use them, they'll have less physical RAM to use and will need to load from the page file.

(This is a workaround rather than an actual fix. More RAM is the best solution, as already noted) .