After a lot of debugging work I have decided to put here a preliminary answer with the description of what I have done, because I was able to solve the issue.
In my opinion it should be simply considered a temporary workaround because, given the past reoccurring behavior I want to keep the things under control and see what could happen with future windows/drivers/bios updates before claiming a definitive victory.
I started to make a series of PC reboot, entering the BIOS each time and disabling one-to-one all the motherboard devices. Every time I cumulatively disabled a single device and then I booted to Windows because I wanted a step by step workflow in order to possibly exactly identify the offending resource.
- disabled CPU VtD, fast boot, logo, block num, Trusted Platform, Power Management, wake on LAN, bios guard: no effect
- disabled serial port: no effect
- disabled CPU integrated graphics: no effect
- disabled unused SATA ports: no effect
- disabled onboard Realtek audio: no effect
- disabled onboard Thunderbolt 3 (Intel Alpine Ridge) controller: no effect
- disabled completely the Intel SATA controller (still able to boot from PCI nvme SSD): no effect
- disabled onboard Intel network adapter AND "IOAPIC 24-119 entries"
(NOTE: at this point only the CPU, PCI slots and USB ports were enabled, impossible to go further): SOLVED!
After the last windows reboot the CPU was on 0.2% and "system and compressed memory" never raised up again.
Too bad that at the last step I made two disabling together and not one alone.
After that I started to step by step re-enable ALL the relevant devices in reverse order and the issue never appeared back. This is really curious and it prevents me to replicate the effect at this point.
However, now are several days the PC works perfectly, I have made some minor windows updates and all is OK. I have still not tried to update to latest Nvidia driver (361.75 released yesterday), but at the moment I will wait because I don't want to recalibrate my monitor and I have seen there are some issues with the preliminary Thunderbolt 3 support added, so I will skip this.
CONCLUSION:
As suspected, the debugging work confirmed to me that the issue was not strictly hardware related (failure or conflict), neither a related driver one (because it was present even in safe mode). In this case it should have been reappeared once the conflicting device was enabled again.
I strongly think that in the past (and twice) something went wrong inside the windows configuration, probably during a windows/driver/bios update, due to an erroneous behavior of Windows resource management. After that happened it was difficult to correctly "override" the setup, even with selective hardware disabling.
After freeing up a lot of resources/irq disabling all the devices the ultimate resolving factor in my opinion was the disabling of the IOPIC 24-119 entries remap: probably this forced windows to reallocate their resources configuration from scratch and this happened successfully. After that even by enabling again the bios setting and the mb devices resulted in any case in a final better configuration without wrongly triggering again the "system and compressed memory" high cpu load (which was caused by the hal.dll -> PCI stuff, as visible in the ETL trace).
Being currently not able to replicate the phenomenon again I will keep the whole issue in stand-by for now.
I will keep this post updated if something else happens or I find something more to share.
I still hope you could appreciate my efforts and that the described results could be useful for someone else.
Thanks, ciao.
Andrea :)
When analyzing the file, I can see that the CPU usage comes from the driver ignis.sys, which is part of Bitdefender AV suite
Line #, DPC/ISR, Process, Stack Tag, Stack, Count, TimeStamp, % Weight
50, , , , | | | | | | | | | | | | | | | | | | |- tcpip.sys!TcpTcbReceive, 37859, , 11,86
51, , , , | | | | | | | | | | | | | | | | | | | |- tcpip.sys!InetInspectReceiveTcpDatagram, 37713, , 11,82
52, , , , | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpTlShimInspectRecvTcpDatagram, 37709, , 11,82
53, , , , | | | | | | | | | | | | | | | | | | | | | |- NETIO.SYS!KfdClassify, 37684, , 11,81
54, , , , | | | | | | | | | | | | | | | | | | | | | | |- NETIO.SYS!ArbitrateAndEnforce, 37675, , 11,80
55, , , , | | | | | | | | | | | | | | | | | | | | | | | |- NETIO.SYS!ProcessCallout, 37666, , 11,80
56, , , , | | | | | | | | | | | | | | | | | | | | | | | | |- ignis.sys!?, 37660, , 11,80
57, , , , | | | | | | | | | | | | | | | | | | | | | | | | | |- ignis.sys!?, 37655, , 11,80
58, , , , | | | | | | | | | | | | | | | | | | | | | | | | | | |- ignis.sys!?, 35814, , 11,22
59, , , , | | | | | | | | | | | | | | | | | | | | | | | | | | | |- ignis.sys!?<itself>, 30047, , 9,42
![enter image description here](https://i.stack.imgur.com/0HYqO.png)
Update or remove Bitdefender.
Best Answer
Analyzing the ETL file with WPA shows, that the CPU usage doesn't come from system memory compression. It comes from
ntoskrnl.exe!MiScrubMemoryWorker
: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.