!heap failed. Invalid type information for ntdll!_HEAP_ENTRY - debugging

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.

Related

*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe

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.

How to disassembly my driver?

I am trying kernel debugging using vmware and windbg.I have connected two OS and all symbols are loaded successfully.If I want to see my driver in memory how can I disassembly that?
I have tried lm commands and lmvm commands
kd> lmvm comint32
start end module name
88da9000 88daf000 comint32 (private pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\comint32.pdb\653387D894B4412FA9E30659E58DD47C1\comint32.pdb
Loaded symbol image file: comint32.sys
Image path: \SystemRoot\System32\Drivers\comint32.sys
Image name: comint32.sys
Timestamp: Thu Apr 11 20:10:55 2013 (51677B3F)
CheckSum: 0000CACF
ImageSize: 00006000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
x comint32!* should dump all the symbols of the module along with their addresses in memory.
You can then either use the u command (with the name (e.g. comint32!DriverEntry) or the address of a function as a parameter) to disassemble into the main window or you can open the disassembly window and paste the name/address into it and browse the disassembled code there.
See your windbg reference for further details.

Application crash on start without exception raised

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

How to determine RVA of AddressOfEntryPoint from PE Headers Using Dumpbin

I have been scouring the web trying to find an answer to this question, but it seems to be eluding me. I have consulting the following sources before asking this question.
http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile.html
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
I understand the PE format (or at least I think I do). Using the command-line debugger (cdb), I would like to be able to disassemble the address where the RVA is to see what the first call is. For a native application (like Notepad), I would expect to see notepad!WinMainCRTStartup, and for a .NET application, I would expect to see a jmp command to the CLR.
Using Notepad as an example, I executed dumpbin /headers on it, and got a value of 3570 for the entry point. When I execute cdb notepad and perform this command - u [base address in memory]+0x3570 - I do not get the WinMainCRTStartup call.
Am I misinterpreting the PE output from dumpbin? How can I know exactly where to look in memory for the starting function of an application?
Edit (1/7/13): I forgot to mention that I am running this on 64-bit Windows 7. If I try to use cdb in Windows XP Mode (to get results from a 32-bit OS), disassembling the AddressOfEntryPoint that I get from an analysis of the PE file gets me the call to WinMainCRTStartup as I would expect. In other words, the exact address I am told to look at contains what I think it should in a 32-bit OS. Does running the application on a 64-bit machine truly make that much of a difference?
Just to add complexity, if I do a !dh on the ImageBaseAddress in the 64-bit OS in cdb, I get the EXACT AddressOfEntryPoint that I need to use.
Use the Microsoft Symbol Server to obtain symbol debugging information. http://support.microsoft.com/kb/311503/en-us
0:001> !dh -a notepad
....
3689 address of entry point
...
00ac0000 image base
...
0:001> u ac3689
notepad!WinMainCRTStartup:
Edit: add dumpbin output (entry point the same offset, image base may be different because ASLR works when image loads in memory):
Microsoft (R) COFF/PE Dumper Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\windows\notepad.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
4 number of sections
4A5BC60F time date stamp Tue Jul 14 03:41:03 2009
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
102 characteristics
Executable
32 bit word machine
OPTIONAL HEADER VALUES
10B magic # (PE32)
9.00 linker version
A800 size of code
22400 size of initialized data
0 size of uninitialized data
3689 entry point (01003689) _WinMainCRTStartup
Edit 2 add output for x64
dumpbin:
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\windows\notepad.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (x64)
6 number of sections
4A5BC9B3 time date stamp Tue Jul 14 03:56:35 2009
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
Application can handle large (>2GB) addresses
OPTIONAL HEADER VALUES
20B magic # (PE32+)
9.00 linker version
A800 size of code
25800 size of initialized data
0 size of uninitialized data
3570 entry point (0000000100003570) WinMainCRTStartup
windbg:
0:000> !dh -a notepad
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
...
1000 base of code
----- new -----
00000000ff0c0000 image base
...
0:000> u ff0c0000+3570
notepad!WinMainCRTStartup:

How to read a google chrome crash dump with windbg

here is what I'm trying to solve. I have a crash dump from Google Chrome.
I open windbg and say File -> Symbol File Path:
"SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com"
I guess this looks for the debugging symbols from let to right and should finally grab them from google then. I copied that from http://www.chromium.org/developers/how-tos/debugging.
I drag and drop the crash dump into windbg
And then...
Microsoft (R) Windows Debugger Version 6.2.8400.0 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\cburgdorf\Desktop\Chrome-last.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed May 16 16:25:24.000 2012 (UTC + 2:00)
System Uptime: not available
Process Uptime: 0 days 0:01:39.000
.........................................
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
eax=00000000 ebx=0038e1f8 ecx=00000001 edx=0012df58 esi=00000002 edi=0038e218
eip=776e013d esp=0038e1a8 ebp=0038e244 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!NtWaitForMultipleObjects+0x15:
776e013d 83c404 add esp,4
0:000> .excr
^ Syntax error in '.excr'
You see that it says "The stored exception information can be accessed via .ecxr" but once I insert that it tells me that I have a syntax error.
Does anyone know what I'm doing wrong?
You've got a typo, it's .ecxr :) In the meantime, another easy way to get information out of a crash dump without needing too much WinDbg-fu, is:
.symfix; .reload
!analyze -v
And if this is a .NET App (Chromium isn't but just for extra info), add these three lines
.loadby sos clr
!pe
~*e !clrstack

Resources