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 […]
April 2nd, 2022 at 12:25 pm
A laptop switched off during dump file write:
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.
Dump completed successfully, progress percentage: 65
Symbol search path is: srv*
Executable search path is:
Missing image name, possible paged-out or corrupt data.
Unable to load image Unknown_Module_65000000`00b7fc41, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Unknown_Module_65000000`00b7fc41
Debugger can not determine kernel base address
Windows 10 Kernel Version 22000 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 22000.1.amd64fre.co_release.210604-1628
Machine Name:
Kernel base = 0xfffff807`3a800000 PsLoadedModuleList = 0xfffff807`3b429b90
Debug session time: Sat Apr 2 13:08:14.826 2022 (UTC + 1:00)
System Uptime: 16 days 13:25:19.305
Page 40500fe039 too large to be in the dump file.
Page 54f0b7fe91 too large to be in the dump file.
Page 9646e65230 too large to be in the dump file.
Page 5f0127b460 too large to be in the dump file.
Page 23cc8250 too large to be in the dump file.
Missing image name, possible paged-out or corrupt data.
Unable to load image Unknown_Module_65000000`00b7fc41, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Unknown_Module_65000000`00b7fc41
Debugger can not determine kernel base address
Loading Kernel Symbols
Missing image name, possible paged-out or corrupt data.
.Unable to read KLDR_DATA_TABLE_ENTRY at 3cb77e4e`2bb76537 - NTSTATUS 0xC0000141
Image path too long, possible corrupt data.
Loading unloaded module list
..Image path too long, possible corrupt data.