A full memory dump but still getting un-mapped sections?

NTDEV
1

I’ve got a full memory dump. Since it’s a “full dump” general assumption is that I should be able to see any frame of any thread provided I have the symbols.

\\

>> The dump info
///

14: kd> .dumpdebug
----- 64 bit Kernel Bitmap Dump Analysis - full address space is available

DUMP_HEADER64:
MajorVersion 0000000f
MinorVersion 00002580
KdSecondaryVersion 00000000
DirectoryTableBase 00000000001aa000 PfnDataBase fffffa8000000000
PsLoadedModuleList fffff8010dd58250 PsActiveProcessHead fffff8010dd3e000
MachineImageType 00008664
NumberProcessors 00000010
BugCheckCode 0000009e
BugCheckParameter1 ffffe801f1e26900 BugCheckParameter2 00000000000004b0
BugCheckParameter3 0000000000000005 BugCheckParameter4 0000000000000000
KdDebuggerDataBlock fffff801`0dd25530
SecondaryDataState 00000000
ProductType 00000003
SuiteMask 00000110
Attributes 00000000

BITMAP_DUMP:
DumpOptions 00000000
HeaderSize 10b000
BitmapSize 83ffff
Pages 7fdd45

KiProcessorBlock at fffff8010dde2d40 16 KiProcessorBlock entries: fffff8010dd82180 ffffd000fbb20180 ffffd000f5f88180 ffffd000f5fc1180 ffffd000f6280180 ffffd000f6300180 ffffd000f6380180 ffffd000fba1b180 ffffd000fbb59180 ffffd000f6480180 ffffd000f6500180 ffffd000f6580180 ffffd000f6600180 ffffd000f6680180 ffffd000f66f9180 ffffd000`f6780180

\\

>> switch to the suspected
///
kd> .process /p /r ffffe801f1e26900
kd> .reload /f /user
kd> lmu

\\

>> dump all thread
///
!process ffffe801f1e26900
~snip~

THREAD ffffe801f144c080 Cid 19b0.1cd0 Teb: 00007ff655d4c000 Win32Thread: fffff901407716b0 WAIT: (WrUserRequest) UserMode Non-Alertable
ffffe0016f3e7da0 SynchronizationEvent
Not impersonating
DeviceMap ffffc000ed40dd80
Owning Process ffffe801f1e26900 Image: xxxx.exe
Attached Process N/A Image: N/A
Wait Start TickCount 380448 Ticks: 109015 (0:00:28:23.359)
Context Switch Count 104 IdealProcessor: 2
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address xxx!WindowThreadRoutine (0x0000000072936638)
Stack Init ffffd000fc5a7c90 Current ffffd000fc5a7510
Base ffffd000fc5a8000 Limit ffffd000fc5a2000 Call 0
Priority 15 BasePriority 13 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Kernel stack not resident.
Child-SP RetAddr Call Site
ffffd000fc5a7550 fffff8010dab278e nt!KiSwapContext+0x76
ffffd000fc5a7690 fffff8010dab2209 nt!KiSwapThread+0x14e
ffffd000fc5a7730 fffff8010dab173d nt!KiCommitThreadWait+0x129
ffffd000fc5a77b0 fffff960000cf958 nt!KeWaitForMultipleObjects+0x1ed
ffffd000fc5a7870 fffff90100000000 0xfffff960000cf958 ffffd000fc5a7878 ffffd000fc5a78d8 0xfffff90100000000
ffffd000fc5a7880 fffff901407716b0 0xffffd000fc5a78d8 ffffd000fc5a7888 000000000000000d 0xfffff901407716b0
ffffd000fc5a7890 0000000040580001 0xd
ffffd000fc5a7898 0000000000000000 0x40580001
~snip~

NOTE: Some frames aren’t visible, even though lmu shows all symbols have been loaded properly

\\

>> loaded module info
///

14: kd> !lmi MSVCR80.dll
Loaded Module Info: [msvcr80.dll]
Module: MSVCR80
Base Address: 00000000763b0000
Image Name: MSVCR80.dll
Machine Type: 34404 (X64)
Time Stamp: 520b0ac2 Tue Aug 13 21:42:42 2013
Size: c9000
CheckSum: cd8fa
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 2a, a7678, a5c78 [Debug data not mapped] - can’t validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
MSVCR80.dll
Symbol Type: PDB - Symbols loaded successfully from image path.
c:\symbols\msvcr80.AMD64.pdb\526D792BD9BA4E5CBB9104FE0BF437781\msvcr80.AMD64.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [8.0 bld 50727]
Load Report: private symbols & lines, not source indexed
c:\symbols\msvcr80.AMD64.pdb\526D792BD9BA4E5CBB9104FE0BF437781\msvcr80.AMD64.pdb

Note: “Debug data not mapped”

kd> !dh MSVCR80.dll

Debug Directories(1)
Type Size Address Pointer
cv 2a a7678 a5c78 Can’t read debug data cb=0


There are more than one modules like MSVCR80.dll whose !lmi and !dh modules output shows “Debug data not mapped” and “Can’t read debug data cb=0”

Question:
Q1: This being a full memory dump is it still possible for few sections of memory to be page-out and hence inaccessible during post-mortem analysis? If no, what can I do access those frames?

Thanks.

2

Crash dump files do not contain page-out data.

3

Thanks for the reply.

Crash dump files do not contain page-out data
OK. But this is very irritating.

Eg.

\\

>> A full memory dump:
///

14: kd> .dumpdebug
----- 64 bit Kernel Bitmap Dump Analysis - full address space is available

DUMP_HEADER64:
MajorVersion 0000000f
MinorVersion 00002580
KdSecondaryVersion 00000000
DirectoryTableBase 00000000001aa000 PfnDataBase fffffa8000000000
PsLoadedModuleList fffff8010dd58250 PsActiveProcessHead fffff8010dd3e000
MachineImageType 00008664
NumberProcessors 00000010
BugCheckCode 0000009e
BugCheckParameter1 ffffe801f1e26900 BugCheckParameter2 00000000000004b0
BugCheckParameter3 0000000000000005 BugCheckParameter4 0000000000000000
KdDebuggerDataBlock fffff801`0dd25530
SecondaryDataState 00000000
ProductType 00000003
SuiteMask 00000110

BITMAP_DUMP:
DumpOptions 00000000
HeaderSize 10b000
BitmapSize 83ffff
Pages 7fdd45

KiProcessorBlock at fffff8010dde2d40 16 KiProcessorBlock entries: fffff8010dd82180 ffffd000fbb20180 ffffd000f5f88180 ffffd000f5fc1180 ffffd000f6280180 ffffd000f6300180 ffffd000f6380180 ffffd000fba1b180 ffffd000fbb59180 ffffd000f6480180 ffffd000f6500180 ffffd000f6580180 ffffd000f6600180 ffffd000f6680180 ffffd000f66f9180 ffffd000`f6780180

\\

>> Note the “Data not mapped”
///

14: kd> !lmi nt
Loaded Module Info: [nt]
Module: ntkrnlmp
Base Address: fffff8010da7f000
Image Name: ntkrnlmp.exe
Machine Type: 34404 (X64)
Time Stamp: 545167e0 Wed Oct 29 15:19:12 2014
Size: 794000
CheckSum: 7266d8
Characteristics: 22
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 25, 1ae00, 1a400 RSDS - GUID:
{0D9A8D6D-F3EF-4915-B019-08C04B2B0D07}
Age: 1, Pdb: ntkrnlmp.pdb
CLSID 4, 1ae3c, 1a43c [Data not mapped]
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\symbols\ntkrnlmp.pdb\0D9A8D6DF3EF4915B01908C04B2B0D071\ntkrnlmp.pdb
Load Report: public symbols , not source indexed

c:\symbols\ntkrnlmp.pdb\0D9A8D6DF3EF4915B01908C04B2B0D071\ntkrnlmp.pdb

\\

>> Simple extensions like !irpfind is not working
///

14: kd> !irpfind
GetPointerFromAddress: unable to read from 0000000000000000
Unable to get MmNonPagedPoolStart

3: kd> x nt!MmNonPagedPoolStart
3: kd> x nt!*MmNonPagedPoolStart*
3: kd> x nt!NonPagedPool*
fffff8020a56a740 nt!NonPagedPoolDescriptor = <no type information><br>fffff8020a5d9c00 nt!NonPagedPoolLock =

4)
The dump is from a Windows 8 PC (not 8.1). I’ve thus tried both debuggers
“6.2.9200.20512 AMD64” and “6.3.9600.17298 AMD64” but I still face the
same issue.

5) Is this by design? For full memory dumps, we cannot even count on being
able to run simple extensions like “!irpfind” or see simple thread stack?
Or am I doing something wrong?

PS: note that customer provided me with another dump, but still the same
issue.

-Gaurav

On Tue, Mar 24, 2015 at 9:25 AM, wrote:

> Crash dump files do not contain page-out data.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>