I am trying to debug a managed core dump, but it is hopeless, because the microsoft symbol server does not seem to contain the symbols for clr.dll version 4.6.1055.0.
Please, observe:
0:022> lmvm clr
Browse full module list
start end module name
73fa0000 74651000 clr (export symbols) clr.dll
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Image name: clr.dll
Browse all global symbols functions data
Timestamp: Thu Nov 5 21:24:51 2015 (563C0F73)
CheckSum: 006B3E43
ImageSize: 006B1000
File version: 4.6.1055.0
Product version: 4.0.30319.0
File flags: 8 (Mask 3F) Private
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® .NET Framework
InternalName: clr.dll
OriginalFilename: clr.dll
ProductVersion: 4.6.1055.0
FileVersion: 4.6.1055.0 built by: NETFXREL2
PrivateBuild: DDBLD400
FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
0:022> .reload /f clr.dll
SYMSRV: BYINDEX: 0xDA
e:\symbols
clr.pdb
1C6AD585F62042AEB690C4C105CB9B962
SYMSRV: e:\symbols\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb - file not found
SYMSRV: e:\symbols\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb not found
SYMSRV: BYINDEX: 0xDB
http://msdl.microsoft.com/download/symbols
clr.pdb
1C6AD585F62042AEB690C4C105CB9B962
SYMSRV: HTTPGET: /download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/clr.pdb
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: HTTPGET: /download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/clr.pd_
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: HTTPGET: /download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/file.ptr
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: C:\ProgramData\dbg\sym\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb - file not found
SYMSRV: http://msdl.microsoft.com/download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/clr.pdb not found
SYMSRV: C:\ProgramData\dbg\sym\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb not found
DBGHELP: clr.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for clr.dll -
DBGHELP: clr - export symbols
************* Symbol Loading Error Summary **************
Module name Error
clr PDB not found : cache*e:\symbols
Unable to locate the .pdb file in this location
The system cannot find the file specified : srv*http://msdl.microsoft.com/download/symbols
The SYMSRV client failed to find a file in the UNC store, or there
is an invalid UNC store (an invalid path or the pingme.txt file is
not present in the root directory), or the file is present in the
symbol server exclusion list.
So, I went to https://developer.microsoft.com/en-us/windows/hardware/download-symbols in hope to download the right symbols. But how do I know which one to download? I did download and installed the ones for Windows 10, x86 32-bit retail symbols of Windows 10 - September 2016 and Windows 10 and Windows Server 2016 - August 2016
But none contained the clr.pdb matching the GUID 1C6AD585F62042AEB690C4C105CB9B962.
What should I do? I am sure there is a better way that downloading and installing all of them.
The web archive has a copy of the desired page from 2016-07-30 where the files seem to be available for download.
If version 4.6.1055.0 of .NET 4.6 was part of the OS at the time it was released, chances are that your clr.pdb is included. I still wonder why it's not available via the official symbol server, but it has happened before that Microsoft simply "forgot" to put it there.
Related
I am trying to analyze crash using cdb.exe from windbg.
I run an windows service to invoke cdb to analyze dmp that i passed in. Then send me the result.
Symbol search path is something like this:
d:\oldstyle;cache*d:\winsyms;srv*http://127.0.0.1:9094/home/apache/winsym
What i actually want is, download symbols from
http://127.0.0.1:9094/home/apache/winsym
and save to
d:\winsyms(local cache)
Problem is something like this:
Unable to load image C:\Windows\System32\combase.dll, Win32 error 0n2
DBGENG: combase.dll - Partial symbol image load missing image info
DBGHELP: Module is not fully loaded into memory.
DBGHELP: Searching for symbols using debugger-provided data.
DBGHELP: d:\oldstyle\combase.pdb - file not found
DBGHELP: d:\oldstyle\dll\combase.pdb - file not found
DBGHELP: d:\oldstyle\symbols\dll\combase.pdb - file not found
SYMSRV: BYINDEX: 0x1F
d:\winsyms
combase.pdb
6D54516506E95F4ABC3FBDAF3373F96D1
SYMSRV: UNC: d:\winsyms\combase.pdb\6D54516506E95F4ABC3FBDAF3373F96D1\combase.pdb - path not found
SYMSRV: UNC: d:\winsyms\combase.pdb\6D54516506E95F4ABC3FBDAF3373F96D1\combase.pd_ - path not found
SYMSRV: UNC: d:\winsyms\combase.pdb\6D54516506E95F4ABC3FBDAF3373F96D1\file.ptr - path not found
SYMSRV: RESULT: 0x80070003
SYMSRV: BYINDEX: 0x20
http://127.0.0.1:9094/home/apache/winsym
combase.pdb
6D54516506E95F4ABC3FBDAF3373F96D1
SYMSRV: UNC: D:\Windows Kits\Debuggers\x64\sym\combase.pdb\6D54516506E95F4ABC3FBDAF3373F96D1\combase.pdb - path not found
SYMSRV: UNC: D:\Windows Kits\Debuggers\x64\sym\combase.pdb\6D54516506E95F4ABC3FBDAF3373F96D1\combase.pd_ - path not found
SYMSRV: UNC: D:\Windows Kits\Debuggers\x64\sym\combase.pdb\6D54516506E95F4ABC3FBDAF3373F96D1\file.ptr - path not found
SYMSRV: HTTPGET: /home/apache/winsym/combase.pdb/6D54516506E95F4ABC3FBDAF3373F96D1/combase.pdb
SYMSRV: WinHttpSendRequest: 800C0057
SYMSRV: RESULT: 0x800C0057
DBGHELP: combase.pdb - file not found
I got "WinHttpSendRequest: 800C0057" after cdb tried to download symbol from my http server.
It's totally ok if i call cdb from a Command Prompt.
I digged and found out:
When running from a Command Prompt, cdb uses WinINet to access internet resources.
When running from a Windows service, cdb uses WinHTTP to access internet resources.
But i found nothing about "WinHttpSendRequest: 800C0057"
Hello Stackoverflow community,
I am trying to debug an application on Windows 10 and require windows debugger framework to load symbols to run certain commands in the (windows kernel debugger) kd.
Each time I load the kernel debugger (kd) on the command prompt by typing kd -kl (NOTE: you would need to enable bcdedit -debug on for it to work), I get the below stack trace:
Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Connected to Windows 10 10240 x64 target at (Tue May 2 18:26:51.800 2017 (UTC - 7:00)), ptr64 TRUE
Symbol search path is: srv*
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Windows 10 Kernel Version 10240 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10240.17354.amd64fre.th1_st1.170327-1827
Machine Name:
Kernel base = 0xfffff803`1da07000 PsLoadedModuleList = 0xfffff803`1dd2c070
Debug session time: Tue May 2 18:26:53.740 2017 (UTC - 7:00)
System Uptime: 0 days 0:50:43.754
lkd>
At first glance, it appears that my sympath is not configured.
I configure it to point to a path on my file system (see next point).
.sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols
Now, I set !sym noisy and do a .reload and I get the following trace
lkd> !sym noisy
noisy mode - symbol prompts off
lkd> .reload
Connected to Windows 10 10240 x64 target at (Tue May 2 18:41:38.542 2017 (UTC - 7:00)), ptr64 TRUE
SYMSRV: BYINDEX: 0x3
c:\symbols*https://msdl.microsoft.com/download/symbols
ntkrnlmp.pdb
30D698E116494C24A48409E2A73883CF1
SYMSRV: c:\symbols\ntkrnlmp.pdb\30D698E116494C24A48409E2A73883CF1\ntkrnlmp.pdb - file not found
SYMSRV: HTTPGET: /download/symbols/ntkrnlmp.pdb/30D698E116494C24A48409E2A73883CF1/ntkrnlmp.pdb
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: HTTPGET: /download/symbols/ntkrnlmp.pdb/30D698E116494C24A48409E2A73883CF1/ntkrnlmp.pd_
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: HTTPGET: /download/symbols/ntkrnlmp.pdb/30D698E116494C24A48409E2A73883CF1/file.ptr
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: c:\symbols\ntkrnlmp.pdb\30D698E116494C24A48409E2A73883CF1\ntkrnlmp.pdb not found
SYMSRV: https://msdl.microsoft.com/download/symbols/ntkrnlmp.pdb/30D698E116494C24A48409E2A73883CF1/ntkrnlmp.pdb not found
DBGHELP: ntkrnlmp.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
DBGHELP: nt - export symbols
Loading Kernel Symbols
...............................................................
................................................................
.........
Loading User Symbols
************* Symbol Loading Error Summary **************
Module name Error
SharedUserData No error - symbol load deferred
Symbol loading has been deferred because this symbol is not needed
at this time. Use reload /f to force load symbols.
ntkrnlmp The system cannot find the file specified
The SYMSRV client failed to find a file in the UNC store, or there
is an invalid UNC store (an invalid path or the pingme.txt file is
not present in the root directory), or the file is present in the
symbol server exclusion list.
I also tried performing the steps explained in ERROR: Symbol file could not be found. windbg.exe and Error:Symbol File not found in WinDbg but no luck. I get errors that indicate several 404 errors.
It always points to this file ntkrnlmp.exe and says its missing(or not found).
Has anyone faced similar issues in the past? If so, what can I do to get this fixed?
The sympath you configured is correct. I think it is very likely because Microsoft has not uploaded the PDB symbol to their symbol servers. Typically new symbols will be available a few days after each Patch Tuesday. (It may become faster in the future.[1]) For your situation, I suggest you to report this issue to Microsoft WinDbg team at windbgfb#microsoft.com with the trace info you posted here.
[1] https://twitter.com/aluhrs13/status/842590084952088580
[2] The email address comes from this page.
I am trying to track what causes my application to crash on start when launched from production. When launched from debug in Visual Studio, this C#/.NET windows application starts without any problem, and results are as expected. Previous versions of the same application have also been deployed and ran on other client computers.
Reading from the explanation found in Windows Error Reporting and CLR integration, it seems my problems comes from a method in assembly ExcelInterop.
Error Bucket , type 0
Event Name : CLR20r3
Answer : Non available
CAB ID : 0
Problem signature :
P1 : afiv2.exe ' my application
P2 : 0.19.4826.21736
P3 : 51489aa0
P4 : ExcelInterop ' my library
P5 : 1.0.0.0
P6 : 514878d9
P7 : 13 ' MethodDescr ???
P8 : 56
P9 : PSZQOADHX1U5ZAHBHOHGHLDGIY4QIXHX
P10 :
Trying to locate the error I launched the application using windbg.exe menu-->File-->Open Executable (first time I use windbg), but console showed that Symbol search path was invalid.
As per Debugging .net using SOS, I recovered symbol path using the following command sequence:
!sym noisy
.symfix
.reload -f
First trial loading SOS lead to an "Unable to find module mscorwks" error, Help:Failed to load sos in windbg solved this part of the problem:
sxe ld:mscorlib
g
.loadby sos mscorwks
!token2ee ExcelInterop 06000013
I expected that the last command would determine the methodDesc associated with the number in the event report, but nothing was returned.
I now feel trapped in a kind of maze. What else should be done to find what is causing the crash on start?
Details of the windbg session
<pre>
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: C:\Users\spel\AppData\Local\Apps\2.0\49619QZC.EY2\B8TZ2OKL.D49\afiv..tion_0000000000000000_0000.0016_22cd035f134c19e0\AFIv2.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 00000000`00290000 00000000`0048e000 AFIv2.exe
ModLoad: 00000000`76f00000 00000000`770a9000 ntdll.dll
ModLoad: 000007fe`f89e0000 000007fe`f8a4f000 C:\Windows\SYSTEM32\MSCOREE.DLL
ModLoad: 00000000`76820000 00000000`7693f000 C:\Windows\system32\KERNEL32.dll
ModLoad: 000007fe`fd450000 000007fe`fd4bb000 C:\Windows\system32\KERNELBASE.dll
(121c.1494): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!CsrSetPriorityClass+0x40:
00000000`76facb60 cc int 3
0:000> .path
^ Syntax error in '.path'
0:000> .winpath
^ Syntax error in '.winpath'
0:000> .sympath
Symbol search path is: <empty>
Expanded Symbol search path is: <empty>
0:000> !sym noisy
noisy mode - symbol prompts on
0:000> .symfix
DBGHELP: Symbol Search Path: cache*C:\ProgramData\dbg\sym;SRV*http://msdl.microsoft.com/download/symbols
0:000> .reload -f
Reloading current modules
.
SYMSRV: C:\ProgramData\dbg\sym\AFIv2.pdb\7C97CCD8E9CD4E26B6039C225A56890B15\AFIv2.pdb not found
SYMSRV: C:\ProgramData\dbg\sym\AFIv2.pdb\7C97CCD8E9CD4E26B6039C225A56890B15\AFIv2.pdb not found
SYMSRV: http://msdl.microsoft.com/download/symbols/AFIv2.pdb/7C97CCD8E9CD4E26B6039C225A56890B15/AFIv2.pdb not found
DBGHELP: C:\Users\spel\AppData\Local\Apps\2.0\49619QZC.EY2\B8TZ2OKL.D49\afiv..tion_0000000000000000_0000.0016_22cd035f134c19e0\AFIv2.pdb - file not found
DBGHELP: C:\Users\spel\Documents\GCRH complet\trunk\AFI_CS\IHM\obj\Debug\AFIv2.pdb cached to C:\ProgramData\dbg\sym\AFIv2.pdb\7C97CCD8E9CD4E26B6039C225A56890B15\AFIv2.pdb
*** WARNING: Unable to verify checksum for AFIv2.exe
DBGHELP: AFIv2 - private symbols & lines
C:\ProgramData\dbg\sym\AFIv2.pdb\7C97CCD8E9CD4E26B6039C225A56890B15\AFIv2.pdb
.
SYMSRV: C:\ProgramData\dbg\sym\kernel32.pdb\C4312728BA1F4691955E99B2E026FAFC2\kernel32.pdb not found
SYMSRV: kernel32.pdb from http://msdl.microsoft.com/download/symbols: 668117 bytes - copied
DBGHELP: C:\ProgramData\dbg\sym\kernel32.pdb\C4312728BA1F4691955E99B2E026FAFC2\kernel32.pdb already cached
DBGHELP: KERNEL32 - public symbols
C:\ProgramData\dbg\sym\kernel32.pdb\C4312728BA1F4691955E99B2E026FAFC2\kernel32.pdb
.
DBGHELP: ntdll - public symbols
C:\ProgramData\dbg\sym\ntdll.pdb\15EB43E23B12409C84E3CC7635BAF5A32\ntdll.pdb
.
SYMSRV: C:\ProgramData\dbg\sym\mscoree.pdb\FB53EF9DD104439E9903F0B34128E0392\mscoree.pdb not found
SYMSRV: mscoree.pdb from http://msdl.microsoft.com/download/symbols: 294166 bytes - copied
DBGHELP: C:\ProgramData\dbg\sym\mscoree.pdb\FB53EF9DD104439E9903F0B34128E0392\mscoree.pdb already cached
DBGHELP: MSCOREE - public symbols
C:\ProgramData\dbg\sym\mscoree.pdb\FB53EF9DD104439E9903F0B34128E0392\mscoree.pdb
.
SYMSRV: C:\ProgramData\dbg\sym\kernelbase.pdb\91C72371DD43448192B7B46F5ED10AA02\kernelbase.pdb not found
SYMSRV: kernelbase.pdb from http://msdl.microsoft.com/download/symbols: 231949 bytes - copied
DBGHELP: C:\ProgramData\dbg\sym\kernelbase.pdb\91C72371DD43448192B7B46F5ED10AA02\kernelbase.pdb already cached
DBGHELP: KERNELBASE - public symbols
C:\ProgramData\dbg\sym\kernelbase.pdb\91C72371DD43448192B7B46F5ED10AA02\kernelbase.pdb
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'
0:000> sxe ld:mscorlib
0:000> g
ModLoad: 000007fe`f35e0000 000007fe`f44bc000 C:\Windows\assembly\NativeImages_v2.0.50727_64\mscorlib\51a23687fdafc32b697f5a719e364651\mscorlib.ni.dll
ntdll!ZwMapViewOfSection+0xa:
00000000`76f5159a c3 ret
0:000> .loadby sos mscorwks
0:000> !token2ee afi 06000013
SYMSRV: C:\ProgramData\dbg\sym\mscorwks.pdb\E5BD5716E1D64C1C86661A5AAF7DD9251\mscorwks.pdb not found
SYMSRV: mscorwks.pdb from http://msdl.microsoft.com/download/symbols: 2000973 bytes - copied
DBGHELP: C:\ProgramData\dbg\sym\mscorwks.pdb\E5BD5716E1D64C1C86661A5AAF7DD9251\mscorwks.pdb already cached
DBGHELP: mscorwks - public symbols
C:\ProgramData\dbg\sym\mscorwks.pdb\E5BD5716E1D64C1C86661A5AAF7DD9251\mscorwks.pdb
0:000> !token2ee ExcelInterop 06000013
</pre>
You could instead set sxe clr which would break on first chance of the exception. And then doing a !clrstack would give call-stack.
The Methoddsec 06000013 could be different based on JIT so you could be looking at pointer that would not give you a result.
HTH
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 understand 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;SRV*C\Symbols*http://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
Product version: 5.2.3790.4789 // does correspond to target computer
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.
UPDATE:
I moved a little bit further in my issue. I managed to connect to the live process on the customers side and tried to
investigate heap (heap -s) there and basically I got the same result.
(1520.7c4): Wake debugger - code 80000007 (first chance)
eax=00000000 ebx=00327d50 ecx=00000000 edx=00000000 esi=0030b428 edi=002debe4
eip=7d61c876 esp=002df008 ebp=002df06c iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll -
ntdll!ZwReadFile+0x15:
7d61c876 c22400 ret 24h
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:000> .reload
Reloading current modules
................................................................
....................................
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
I think I have a problem similar to one mentioned in this article http://support.microsoft.com/kb/959207.
Environment and problem seem to be the same but dll versions are different, so it is not the solution for me.
I think I have to escalate this problem to Microsoft.
Does anybody know where I should go with this question?
This could happen if dump was created with 64 bit tools. There is good information on Tess's blog that explains the reason why bitness of the dump matters.
The solution appears to be easy but not obvious.
I found a wntdll.pdb slightly bigger than mine which contains required symbols and reloaded it with command .reload /f /i ntdll.dll
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.
It looks like the type _HEAP_ENTRY is not included in the pdb of 2003 SP2 ntdll.dll
Microsoft released a hotfix http://support.microsoft.com/kb/959207, but you seem to have a later ntdll version.
I have a minidump crashed from a .NET application. Is there any way to know the CLR version (e.g. version of mscorwks.dll) of the fault machine (which generates the crash dump) using either Windbg or some other tool?
In WinDbg: the easiest way is to use the !eeversion command, but if you want additional info you can use the lm command with the v verbose option for the runtime module mscorwks. If you're on .NET 4 the runtime is called clr, so in that case you need to change the command accordingly.
0:026> lm vm mscorwks
start end module name
79e70000 7a3ff000 mscorwks T (no symbols)
Loaded symbol image file: mscorwks.dll
Image path: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Image name: mscorwks.dll
Timestamp: Wed Oct 24 09:41:29 2007 (471EF729)
CheckSum: 00597AA8
ImageSize: 0058F000
File version: 2.0.50727.1433
Product version: 2.0.50727.1433
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
!EEVersion should give the CLR version.
Go verbose in WinDbg:
>lm v
............. (lots of modules).......
687d0000 68d06000 System_Xml_ni (deferred)
Image path: C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Xml\38b9d09539b67b08ee996db6c71f8a9b\System.Xml.ni.dll
Image name: System.Xml.ni.dll
Has CLR image header, track-debug-data flag not set
Timestamp: Mon Oct 06 20:43:49 2008 (48EADAF5)
CheckSum: 00000000
ImageSize: 00536000
File version: 2.0.50727.3074
Product version: 2.0.50727.3074
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® .NET Framework
InternalName: System.Xml.dll
OriginalFilename: System.Xml.dll
ProductVersion: 2.0.50727.3074
FileVersion: 2.0.50727.3074 (QFE.050727-3000)
FileDescription: .NET Framework
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
Alternatively, load the dump in Visual Studio and use the Debug | Windows | Modules toolwindow to display some of this info.
Examples for two different .Net versions, using the version information of clr.dll:
.Net 4.0(.x?)
Image name: clr.dll
Timestamp: Thu Mar 18 21:39:07 2010 (4BA21EEB)
...
File version: 4.0.30319.1
Product version: 4.0.30319.1
.Net 4.5.2
Image name: clr.dll
Timestamp: Fri Nov 07 20:09:21 2014 (545CA861)
...
File version: 4.5.27.0
Product version: 4.0.30319.0