It came to my attention that almost every huge or not so x64 kernel or complete memory dump is diagnosed with excessive pool usage. Sometimes it is too excessive like in the following example:
0: kd> !vm
*** Virtual Memory Usage ***
Physical Memory: 8387414 ( 33549656 Kb)
Page File: \??\D:\pagefile.sys
Current: 33856856 Kb Free Space: 33855520 Kb
Minimum: 33856856 Kb Maximum: 46364420 Kb
Available Pages: 7231844 ( 28927376 Kb)
ResAvail Pages: 7763458 ( 31053832 Kb)
Locked IO Pages: 0 ( 0 Kb)
Free System PTEs: 33556220 ( 134224880 Kb)
Modified Pages: 2759 ( 11036 Kb)
Modified PF Pages: 2759 ( 11036 Kb)
NonPagedPool Usage: 650867425 (2603469700 Kb)
NonPagedPoolNx Usage: 83715 ( 334860 Kb)
NonPagedPool Max: 6271754 ( 25087016 Kb)
********** Excessive NonPaged Pool Usage *****
PagedPool 0 Usage: 48923 ( 195692 Kb)
PagedPool 1 Usage: 39797 ( 159188 Kb)
PagedPool 2 Usage: 37412 ( 149648 Kb)
PagedPool 3 Usage: 37536 ( 150144 Kb)
PagedPool 4 Usage: 37453 ( 149812 Kb)
PagedPool Usage: 201121 ( 804484 Kb)
PagedPool Maximum: 33554432 ( 134217728 Kb)
Session Commit: 15829 ( 63316 Kb)
Shared Commit: 7198 ( 28792 Kb)
Special Pool: 0 ( 0 Kb)
Shared Process: 158498 ( 633992 Kb)
PagedPool Commit: 201147 ( 804588 Kb)
Driver Commit: 5761 ( 23044 Kb)
Committed pages: 1126203 ( 4504812 Kb)
Commit limit: 16851145 ( 67404580 Kb)
What we can see above is that the amount of used nonpaged pool is more than 2.5 Tb which is far less than the amount of physical memory + page file size (both in total do not exceed 100 Gb). So I conclude that Windows architects did the impossible and are able to create information (pages) from vacuum like matter can be created from vacuum fluctuations. Perhaps they are a step closer to implement some features from Cantor OS.
- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -