!heap failed in windbg. Invalid type information for ntdll!_HEAP_ENTRY

WINDBG
1

Hello,

I’m trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86.
Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine.
From the following windbg log I see that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols.
I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard location (c:\windows\system32).

What did I do wrong? How to force windbg to load correct version of ntdll?


Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

[… skipped …]

0:042> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
kernel32.dll version: 5.2.3790.4480 (srv03_sp2_gdr.090321-1244)
Machine Name:
Debug session time: Wed Mar 16 16:36:10.000 2011 (GMT-5)
System Uptime: 17 days 10:34:26.068
Process Uptime: 1 days 15:19:14.000
Kernel time: 0 days 1:24:01.000
User time: 0 days 22:07:58.000

0:042> .sympath
Symbol search path is: C:\mscordacwks\v2.0.50727.3615;C:\ exe;SRVC\Symbolshttp://referencesource.microsoft.com/symbols;SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*http://source.msdn.microsoft.com/symbols

0:042> .exepath
Executable image search path is: C: exe;C:__target\Windows\SysWOW64;

0:042> .reload

[… skipped …]

0:042> .reload /u ntdll.dll
Unloaded ntdll.dll
0:042> .reload /v /f ntdll.dll
AddImage: C:\WINDOWS\system32\ntdll.dll ///// why is it still c:\windows\system32
DllBase = 7d600000
Size = 000f0000
Checksum = 000c371a
TimeDateStamp = 4cc1831e

0:042> lm
[… skipped …]
7d600000 7d6f0000 ntdll (pdb symbols) c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb

0:042> !heap

Your debugger is not using the correct symbols
[… skipped …]
 Type referenced: ntdll!_HEAP_ENTRY

Invalid type information

0:042> lmi vm ntdll
start end module name
7d600000 7d6f0000 ntdll (pdb symbols) ntdll.dll
Symbol file: c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
Image path: C:\WINDOWS\system32\ntdll.dll
Image name: ntdll.dll
Timestamp: Fri Oct 22 07:27:10 2010 (4CC1831E)
CheckSum: 000C371A
ImageSize: 000F0000
File version: 5.2.3790.4789 ///// this is correct and correspond to target computer
Product version: 5.2.3790.4789
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: MicrosoftR WindowsR Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 5.2.3790.4789
FileVersion: 5.2.3790.4789 (srv03_sp2_gdr.101019-0340)
FileDescription: NT Layer DLL
LegalCopyright: c Microsoft Corporation. All rights reserved.

—
BR,
Alexei

2

!heap gets confused by 64-bit dumps of 32-bit processes. You may be able to work around this by manually reloading wow64 ntdll as “ntdll.dll”:

0:000> .load wow64exts
0:000> !sw
Switched to 32bit mode

0:000:x86> .reload /u ntdll
Unloaded ntdll

0:000:x86> lmm ntdll*
start end module name
77520000 776a0000 ntdll_77520000 (deferred)

0:000:x86> ? 776a0000-77520000
Evaluate expression: 1572864 = 00180000

0:000:x86> .reload ntdll.dll=77520000,180000

0:000:x86> !heap
** !heap: Could not determine WOW64 module name, some results may be missing
Index Address Name Debugging options enabled
1: 00890000
2: 00590000
3: 00e80000
4: 03360000
5: 034b0000
6: 036d0000
7: 04190000

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@snkmail.com
Sent: Thursday, March 17, 2011 8:46 AM
To: Kernel Debugging Interest List
Subject: [windbg] !heap failed in windbg. Invalid type information for ntdll!_HEAP_ENTRY

Hello,

I’m trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86.
Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine.
From the following windbg log I see that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols.
I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard location (c:\windows\system32).

What did I do wrong? How to force windbg to load correct version of ntdll?


Microsoft (R) Windows Debugger Version 6.11.0001.404 X86 Copyright (c) Microsoft Corporation. All rights reserved.

[… skipped …]

0:042> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS kernel32.dll version: 5.2.3790.4480 (srv03_sp2_gdr.090321-1244) Machine Name:
Debug session time: Wed Mar 16 16:36:10.000 2011 (GMT-5) System Uptime: 17 days 10:34:26.068 Process Uptime: 1 days 15:19:14.000
Kernel time: 0 days 1:24:01.000
User time: 0 days 22:07:58.000

0:042> .sympath
Symbol search path is: C:\mscordacwks\v2.0.50727.3615;C:\ exe;SRVC\Symbolshttp://referencesource.microsoft.com/symbols;SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*http://source.msdn.microsoft.com/symbols

0:042> .exepath
Executable image search path is: C: exe;C:__target\Windows\SysWOW64;

0:042> .reload

[… skipped …]

0:042> .reload /u ntdll.dll
Unloaded ntdll.dll
0:042> .reload /v /f ntdll.dll
AddImage: C:\WINDOWS\system32\ntdll.dll ///// why is it still c:\windows\system32 DllBase = 7d600000
Size = 000f0000
Checksum = 000c371a
TimeDateStamp = 4cc1831e

0:042> lm
[… skipped …]
7d600000 7d6f0000 ntdll (pdb symbols) c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb

0:042> !heap

 Your debugger is not using the correct symbols
[… skipped …]
 Type referenced: ntdll!_HEAP_ENTRY

Invalid type information

0:042> lmi vm ntdll
start end module name
7d600000 7d6f0000 ntdll (pdb symbols) ntdll.dll
Symbol file: c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
Image path: C:\WINDOWS\system32\ntdll.dll
Image name: ntdll.dll
Timestamp: Fri Oct 22 07:27:10 2010 (4CC1831E)
CheckSum: 000C371A
ImageSize: 000F0000
File version: 5.2.3790.4789 ///// this is correct and correspond to target computer
Product version: 5.2.3790.4789
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: MicrosoftR WindowsR Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 5.2.3790.4789
FileVersion: 5.2.3790.4789 (srv03_sp2_gdr.101019-0340)
FileDescription: NT Layer DLL
LegalCopyright: c Microsoft Corporation. All rights reserved.

—
BR,
Alexei

—
WINDBG is sponsored by OSR

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

3

Sorry for the late response.

The dump is 32 bits created on 64 bits system. I can see it trying to switch the mode in windbg.

0:042> .load wow64exts
0:042> !sw
!wow64exts.sw : command invalid on non-64bit target

Maybe this is the reason (32 bits dump created on 64 bits system) why I cannot load ntdll.dll from another location. Looks like a bug in WinDbg.

BR,
Alexei

4

This is a long standing issue and Microsoft are aware of it. We became so frustrated with it that we managed to get our company to officially submit the problem to Microsoft late last year. We were told that Microsoft acknowledged the problem, could reproduce it at will, and had given it to engineering to address. I have heard nothing further.

We were told that the problem existed when a 64bit process initiated the dump of a 32 bit process. A 32bit process initiating the dump of a 32bit process under wow64 apparently produces a pure 32bit dump. That’s all fine and good except where you have little control over who or what creates the dumps.

5

Thanks Gerard. That is really sad.
Do you think creating 64 bits dump would allow me to look at the memory?

BR,
Alexei

6

I’m sorry I don’t know the answer to the question. Only a dev who knows what goes wrong with dumping in these mixed environments can tell us the ins and outs.

The advice we received appears good. When you initiate a dump of a 32 bit process running in 64 bit windows do so using a 32 bit tool (your own, or for example, debugdiag).

7

The solution appears to be easy but not obvious.

  1. I found wntdll.pdb slightly bigger than mine which contains required symbols and reload it with command .reload /f /i ntdll.dll
  2. and I take the previous build of windbg 6.11.0001.404, in the current one 6.12.0002.633 !heap command still does not work in my case.