__sa__nya
21-04-2019, 09:20
Доброе время суток. Читаю одну интересную книгу по анализу дампов (в т.ч. BSOD ). В качестве примера ОС в книге используются XP и Vista ( знаю что уже устарели но интересного все равно для меня много). В этой книге приводится пример когда эти системы могли "падать" в BSOD из-за нехватки оперативы, код 8E. Подчеркну - с самими модулями все в порядке, не "битые", просто может не хватать и система падает.
Вопрос: были ли у кого подобные факты на OS Windows начиная с Windows 7 ?
PS: ниже вырезка из книги где объясняется и показывается почему система упала именно из-за нехватки памяти:
INSUFFICIENT MEMORY (COMMITTED MEMORY)
Insufficient Memory pattern can be seen in many complete and kernel memory dumps. This condition can cause a system to crash, become slow, hang or refuse to pro-vide the expected functionality, for example, refuse new terminal server connections. There are many types of memory resources and we can classify them initially into the following categories: Committed memory Virtual memory
o Kernel space
Paged pool
Non-paged pool
Session pool
PTE limits
Desktop heap
GDI limits
o User space
Virtual regions
Process heap
What we outline here is committed memory exhaustion. Committed memory is an allocated memory backed up by some physical memory or by a reserved space in the page file(s). Reserving the space needs to be done in case OS wants to swap out that memory data to disk when it is not used and there is no physical memory available for other processes. If that data is needed again OS brings it back to physical memory. If there is no space in page file(s) then physical memory is filled up. If committed memory is exhausted most likely the system will hang or result in a bugcheck soon so checking memory statistics shall always be done when we get a kernel or a complete memory dump. Even access violation bugchecks could result from insufficient memory when some memory allocation operation failed but a kernel mode component didn’t check the return value for NULL. Here is an example: BugCheck 8E, {c0000005, 809203af, aa647c0c, 0}
0: kd> !analyze -v ... ... ... TRAP_FRAME: aa647c0c -- (.trap ffffffffaa647c0c) ...
Insufficient Memory (Committed Memory) 303
... ...
0: kd> .trap ffffffffaa647c0c ErrCode = 00000000 eax=00000000 ebx=bc1f3cfc ecx=89589250 edx=000018c1 esi=bc1f3ce0 edi=aa647d14 eip=809203af esp=aa647c80 ebp=aa647c80 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 nt!SeTokenType+0x8: 809203af 8b8080000000 mov eax,dword ptr [eax+80h] ds:0023:00000080=???????? 0: kd> k ChildEBP RetAddr aa647c80 bf8173c5 nt!SeTokenType+0x8 aa647cdc bf81713b win32k!GreGetSpoolMessage+0xb0 aa647d4c 80834d3f win32k!NtGdiGetSpoolMessage+0x96 aa647d4c 7c82ed54 nt!KiFastCallEntry+0xfc
If we enter !vm command to display memory statistics we would see that all committed memory is filled up:
0: kd> !vm *** Virtual Memory Usage *** Physical Memory: 999294 ( 3997176 Kb) Page File: \??\C:\pagefile.sys Current: 4193280 Kb Free Space: 533744 Kb Minimum: 4193280 Kb Maximum: 4193280 Kb Available Pages: 18698 ( 74792 Kb) ResAvail Pages: 865019 ( 3460076 Kb) Locked IO Pages: 290 ( 1160 Kb) Free System PTEs: 155265 ( 621060 Kb) Free NP PTEs: 32766 ( 131064 Kb) Free Special NP: 0 ( 0 Kb) Modified Pages: 113 ( 452 Kb) Modified PF Pages: 61 ( 244 Kb) NonPagedPool Usage: 12380 ( 49520 Kb) NonPagedPool Max: 64799 ( 259196 Kb) PagedPool 0 Usage: 40291 ( 161164 Kb) PagedPool 1 Usage: 2463 ( 9852 Kb) PagedPool 2 Usage: 2455 ( 9820 Kb) PagedPool 3 Usage: 2453 ( 9812 Kb) PagedPool 4 Usage: 2488 ( 9952 Kb) PagedPool Usage: 50150 ( 200600 Kb) PagedPool Maximum: 67584 ( 270336 Kb)
********** 18 pool allocations have failed **********
Shared Commit: 87304 ( 349216 Kb) Special Pool: 0 ( 0 Kb)
304 PART 3: Crash Dump Analysis Patterns
Shared Process: 56241 ( 224964 Kb) PagedPool Commit: 50198 ( 200792 Kb) Driver Commit: 1892 ( 7568 Kb) Committed pages: 2006945 ( 8027780 Kb) Commit limit: 2008205 ( 8032820 Kb) ********** 1216024 commit requests have failed ********** There might have been a memory leak or too many terminal sessions with fat applications to fit in physical memory and the page file.
Вопрос: были ли у кого подобные факты на OS Windows начиная с Windows 7 ?
PS: ниже вырезка из книги где объясняется и показывается почему система упала именно из-за нехватки памяти:
INSUFFICIENT MEMORY (COMMITTED MEMORY)
Insufficient Memory pattern can be seen in many complete and kernel memory dumps. This condition can cause a system to crash, become slow, hang or refuse to pro-vide the expected functionality, for example, refuse new terminal server connections. There are many types of memory resources and we can classify them initially into the following categories: Committed memory Virtual memory
o Kernel space
Paged pool
Non-paged pool
Session pool
PTE limits
Desktop heap
GDI limits
o User space
Virtual regions
Process heap
What we outline here is committed memory exhaustion. Committed memory is an allocated memory backed up by some physical memory or by a reserved space in the page file(s). Reserving the space needs to be done in case OS wants to swap out that memory data to disk when it is not used and there is no physical memory available for other processes. If that data is needed again OS brings it back to physical memory. If there is no space in page file(s) then physical memory is filled up. If committed memory is exhausted most likely the system will hang or result in a bugcheck soon so checking memory statistics shall always be done when we get a kernel or a complete memory dump. Even access violation bugchecks could result from insufficient memory when some memory allocation operation failed but a kernel mode component didn’t check the return value for NULL. Here is an example: BugCheck 8E, {c0000005, 809203af, aa647c0c, 0}
0: kd> !analyze -v ... ... ... TRAP_FRAME: aa647c0c -- (.trap ffffffffaa647c0c) ...
Insufficient Memory (Committed Memory) 303
... ...
0: kd> .trap ffffffffaa647c0c ErrCode = 00000000 eax=00000000 ebx=bc1f3cfc ecx=89589250 edx=000018c1 esi=bc1f3ce0 edi=aa647d14 eip=809203af esp=aa647c80 ebp=aa647c80 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 nt!SeTokenType+0x8: 809203af 8b8080000000 mov eax,dword ptr [eax+80h] ds:0023:00000080=???????? 0: kd> k ChildEBP RetAddr aa647c80 bf8173c5 nt!SeTokenType+0x8 aa647cdc bf81713b win32k!GreGetSpoolMessage+0xb0 aa647d4c 80834d3f win32k!NtGdiGetSpoolMessage+0x96 aa647d4c 7c82ed54 nt!KiFastCallEntry+0xfc
If we enter !vm command to display memory statistics we would see that all committed memory is filled up:
0: kd> !vm *** Virtual Memory Usage *** Physical Memory: 999294 ( 3997176 Kb) Page File: \??\C:\pagefile.sys Current: 4193280 Kb Free Space: 533744 Kb Minimum: 4193280 Kb Maximum: 4193280 Kb Available Pages: 18698 ( 74792 Kb) ResAvail Pages: 865019 ( 3460076 Kb) Locked IO Pages: 290 ( 1160 Kb) Free System PTEs: 155265 ( 621060 Kb) Free NP PTEs: 32766 ( 131064 Kb) Free Special NP: 0 ( 0 Kb) Modified Pages: 113 ( 452 Kb) Modified PF Pages: 61 ( 244 Kb) NonPagedPool Usage: 12380 ( 49520 Kb) NonPagedPool Max: 64799 ( 259196 Kb) PagedPool 0 Usage: 40291 ( 161164 Kb) PagedPool 1 Usage: 2463 ( 9852 Kb) PagedPool 2 Usage: 2455 ( 9820 Kb) PagedPool 3 Usage: 2453 ( 9812 Kb) PagedPool 4 Usage: 2488 ( 9952 Kb) PagedPool Usage: 50150 ( 200600 Kb) PagedPool Maximum: 67584 ( 270336 Kb)
********** 18 pool allocations have failed **********
Shared Commit: 87304 ( 349216 Kb) Special Pool: 0 ( 0 Kb)
304 PART 3: Crash Dump Analysis Patterns
Shared Process: 56241 ( 224964 Kb) PagedPool Commit: 50198 ( 200792 Kb) Driver Commit: 1892 ( 7568 Kb) Committed pages: 2006945 ( 8027780 Kb) Commit limit: 2008205 ( 8032820 Kb) ********** 1216024 commit requests have failed ********** There might have been a memory leak or too many terminal sessions with fat applications to fit in physical memory and the page file.