A few days ago, a friend found me and said that his machine has a constant **, but I can't find out which process eats the memory in the task manager, which is particularly strange, and the screenshot is as follows:
In my analysis journey, it is all the memory leaks of the user-mode mode, as the abnormal signs in the above figure have clearly told you, it is not the user-mode program that eats the memory, that is the kernel mode program eats, for example:
Some driver operating systems are generally caused by memory leaks of some third-party programs in terms of probability, and in this article, we will talk about how to solve this problem.
I believe that many friends know that user-mode programs directly or indirectly call virtualalloc methods to ask the operating system for memory, including the GC heap of c, and its method signature is as follows:
lpvoid virtualalloc( [in, optional] lpvoid lpaddress, [in] size_t dwsize, [in] dword flallocationtype, [in] dword flprotect);declspec_restrict pvoid exallocatepool2( pool_flags flags, size_t numberofbytes, ulong tag);The flags parameter is generally used in two types: pool flag non paged and pool flag paged, the former indicates that the allocated memory needs to be permanently retained in memory and cannot be exchanged to a hard disk. The memory allocated by the latter is swappable to the hard disk.
The original intention of the tag parameter is to facilitate the insight into memory leaks in the future, it forcibly binds a piece of memory to the tag (a 4byte ASCII string), and then you will know who allocated the memory through this tag.
In order to be able to leak the driver, you can use the notmyfault tool provided by Microsoft, which makes use of MyFaultThe sys driver constantly allocates memory to the operating system. **For:
Open the MyFault tool and enter 40ms of leakage, and allocate it to the non-page swap pool, and configure the kernel state dump, * and screenshot as follows
exallocatepool2(pool_flag_non_paged,40*1024*1024,"leak");
In the course of the breach, it was evident through Process Explorer that 67G of RAM, of which there are 49g is distributed in nonpaged, i.e. by the pool flag non paged tag in the image above, screenshot below:
Next, switch to the Crash tab on MyFault and force the OS to blue screen to generate the dump file.
Once you get the dump, pass first!VMs observe the distribution of virtual memory at the operating system level.
3: kd> !vm...physical memory: 2069421 ( 8277684 kb)**ailable pages: 445015 ( 1780060 kb)res**ail pages: 707292 ( 2829168 kb)locked io pages: 0 ( 0 kb)free system ptes: 4295052431 (17180209724 kb)..modified pages: 11479 ( 45916 kb)modified pf pages: 11479 ( 45916 kb)modified no write pages: 0 ( 0 kb)nonpagedpool usage: 1219892 ( 4879568 kb)nonpagedpoolnx usage: 24512 ( 98048 kb)nonpagedpool max: 4294967296 (17179869184 kb)pagedpool usage: 32907 ( 131628 kb)pagedpool maximum: 4294967296 (17179869184 kb)..nonpagedpool commit: 1246469 ( 4985876 kb)..sum system commit: 1409562 ( 5638248 kb)total private: 279673 ( 1118692 kb)**sum of individual system commit + process commit exceeds overall commit by 1952 kb ? committed pages: 1688747 ( 6754988 kb)commit limit: 4166573 ( 16666292 kb)The next step is to dig deep into the non-page swap pool and see what tag is allocated, which can be used!poolused 2 command.
3: kd> !poolused 2...sorting by nonpaged pool consumed nonpaged paged tag allocs used allocs used leak 119 4991221760 0 0 unknown pooltag 'leak', please update pooltag.txt cont 238 14499840 0 0 unknown pooltag 'cont', please update pooltag.txt ketr 16410 8117664 0 0 unknown pooltag 'ketr', please update pooltag.txt etwb 196 7565568 2 131072 etw buffer , binary: nt!etw 2872 6 5660864 0 0 unknown pooltag '2872', please update pooltag.txt 287r 1026 4183040 0 0 unknown pooltag '287r', please update pooltag.txt file 9734 3877408 0 0 file objects thre 1257 3217920 0 0 thread objects , binary: nt!ps etwr 12141 2672640 0 0 etw km regentry , binary: nt!etw...The next question is: which driver is responsible for this leak?The easiest way to do this is to do a memory search in the memory space of each driver to see who has the ASC hardcode of leak in it, right, with this idea, use LM to see what sys are in it.
3: kd> lmstart end module nameffffc25c`891b0000 ffffc25c`89480000 win32kbase (deferred) ffffc25c`8a190000 ffffc25c`8a545000 win32kfull (deferred) .fffff807`22600000 fffff807`23646000 nt (pdb symbols) fffff807`23c00000 fffff807`23d16000 clipsp (deferred) fffff807`47f30000 fffff807`47f4b000 monitor (deferred) fffff807`47f50000 fffff807`47f59000 myfault (deferred) .unloaded modules:fffff807`3c6e0000 fffff807`3c6ec000 360sensor64.sysfffff807`31550000 fffff807`31560000 dump_storport.sysfffff807`315a0000 fffff807`315d3000 dump_storahci.sysfffff807`31000000 fffff807`3101e000 dump_dumpfve.sysfffff807`26b80000 fffff807`26bac000 luafv.sysfffff807`26b20000 fffff807`26b30000 dump_storport.sysfffff807`26b70000 fffff807`26ba3000 dump_storahci.sysfffff807`26bd0000 fffff807`26bee000 dump_dumpfve.sysfffff807`28130000 fffff807`2814c000 dam.sys fffff807`24200000 fffff807`2420a000 360elam64.sysfffff807`25230000 fffff807`25241000 hwpolicy.sys3: kd> lmvm myfaultbrowse full module liststart end module namefffff807`47f50000 fffff807`47f59000 myfault (deferred) image path: \c:\windows\system32\drivers\myfault.sys image name: myfault.sys browse all global symbols functions data timestamp: fri sep 30 00:17:31 2022 (6335c51b) checksum: 00010ced imagesize: 00009000 translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 information from resource tables: 3: kd> ?fffff807`47f59000 - fffff807`47f50000evaluate expression: 36864 = 00000000`000090003: kd> s -a fffff807`47f50000 l?0x9000 "leak"fffff807`47f51559 4c 65 61 6b 0f 42 c1 41-8d 49 fd 8b d0 ff 15 0c leak.b.a.i...fffff807`47f515c7 4c 65 61 6b 0f 42 c1 33-c9 8b d0 ff 15 a0 1a 00 leak.b.3...