Crash Dump Analysis Patterns (Part 18)
Sometimes the page file size is less than the amount of physical memory. If this is the case and we have configured “Complete memory dump” in Startup and Recovery settings in Control Panel we get truncated dumps. Therefore we can call our next pattern “Truncated Dump”. WinDbg prints a warning when we open such dump:
************************************************************
WARNING: Dump file has been truncated. Data may be missing.
************************************************************
We can double check this with !vm command:
kd> !vm
*** Virtual Memory Usage ***
Physical Memory: 511859 ( 2047436 Kb)
Paging File Name paged out
Current: 1536000 Kb Free Space: 1522732 Kb
Minimum: 1536000 Kb Maximum: 1536000 Kb
We see that the page file size is 1.5Gb but the amount of physical memory is 2Gb. When BSOD happens the physical memory contents will be saved to the page file and the dump file size will be no more than 1.5Gb effectively truncating data needed for crash dump analysis.
Sometimes you can still access some data in truncated dumps but pay attention to what WinDbg says. For example, in the truncated dump shown above the stack and driver code are not available:
kd> kv
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
f408b004 00000000 00000000 00000000 00000000 driver+0x19237
kd> r
Last set context:
eax=89d55230 ebx=89d21130 ecx=89d21130 edx=89c8cc20 esi=89e24ac0 edi=89c8cc20
eip=f7242237 esp=f408afec ebp=f408b004 iopl=0 nv up ei ng nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
driver+0x19237:
f7242237 ?? ???
kd> dds esp
f408afec ????????
f408aff0 ????????
f408aff4 ????????
f408aff8 ????????
f408affc ????????
f408b000 ????????
f408b004 ????????
f408b008 ????????
f408b00c ????????
f408b010 ????????
f408b014 ????????
f408b018 ????????
f408b01c ????????
f408b020 ????????
f408b024 ????????
f408b028 ????????
f408b02c ????????
f408b030 ????????
f408b034 ????????
f408b038 ????????
f408b03c ????????
f408b040 ????????
f408b044 ????????
f408b048 ????????
f408b04c ????????
f408b050 ????????
f408b054 ????????
f408b058 ????????
f408b05c ????????
f408b060 ????????
f408b064 ????????
f408b068 ????????
kd> lmv m driver
start end module name
f7229000 f725f000 driver T (no symbols)
Loaded symbol image file: driver.sys
Image path: driver.sys
Image name: driver.sys
Timestamp: unavailable (FFFFFFFE)
CheckSum: missing
ImageSize: 00036000
kd> dd f7229000
f7229000 ???????? ???????? ???????? ????????
f7229010 ???????? ???????? ???????? ????????
f7229020 ???????? ???????? ???????? ????????
f7229030 ???????? ???????? ???????? ????????
f7229040 ???????? ???????? ???????? ????????
f7229050 ???????? ???????? ???????? ????????
f7229060 ???????? ???????? ???????? ????????
f7229070 ???????? ???????? ???????? ????????
If due to some reasons you cannot increase the size of your page file then just configure “Kernel memory dump” in Startup and Recovery. For most all bugchecks kernel memory dump is sufficient except manual crash dumps when you need to inspect user process space.
- Dmitry Vostokov @ DumpAnalysis.org -
October 29th, 2008 at 8:03 pm
[…] the common mistake of not looking at all stack traces. This important when the dump is partially truncated or inconsistent. For example, in one complete memory dump from one hang system WinDbg !locks […]
October 30th, 2008 at 4:49 pm
[…] memory dumps could be smaller than the actual amount of physical memory and even when possibly truncated with many OS structures being included. For the virtual memory stats above the size of complete […]
September 10th, 2009 at 3:16 pm
[…] this nonsense I checked that complete dump was truncated by half because page file was 4Gb but the amount of physical memory was […]
May 7th, 2010 at 2:08 pm
[…] we introduce an icon for Truncated Dump […]
August 13th, 2010 at 7:16 pm
[…] We also see that this thread spent more than a minute in user mode. Unfortunately we cannot see its thread stack because the dump shows signs of Truncated Dump pattern: […]
September 24th, 2010 at 10:55 am
[…] Truncated Dump […]