Failed to read emergency crash in windbg

Question

I get a stackoverflow exception in my program that may come from a third party libparty, microsoft.sharepoint.client.runtime.dll.

Using adplus to create a crash dump, I ran into a problem due to which I struggle to get information from it when I open it in windbg. This is what I get in response:

 > 0:000> .restart /f Loading Dump File [C:\symbols\FULLDUMP_FirstChance_epr_Process_Shut_Down_DocumentumMigrator.exe__0234_2011-11-17_15-19-59-426_0d80.dmp] User Mini Dump File with Full Memory: Only application data is available Comment: 'FirstChance_epr_Process_Shut_Down' Symbol search path is: C:\symbols Executable search path is: Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64 Product: Server, suite: Enterprise TerminalServer SingleUserTS Machine Name: Debug session time: Thu Nov 17 15:19:59.000 2011 (UTC + 2:00) System Uptime: 2 days 2:44:48.177 Process Uptime: 0 days 0:13:05.000 .........................................WARNING: rsaenh overlaps cryptsp .................WARNING: rasman overlaps apphelp ...... ..WARNING: webio overlaps winhttp .WARNING: credssp overlaps mswsock .WARNING: IPHLPAPI overlaps mswsock .WARNING: winnsi overlaps mswsock ............ wow64cpu!CpupSyscallStub+0x9: 00000000`74e42e09 c3 ret 

Any ideas on how I can get more information from the dump, or how to use it to find where the stackoverflow error occurs?

Answer 1

The problem you are facing is that the process is 32-bit, but you are running on 64-bit, so your dump is a 64-bit dump. To use the dump, you must run the following commands:

 .load wow64exts .effmach x86 !analyze -v 

The last command should give you meaningful stack trace.

Answer 2

This page contains a lot of useful information and a method for analyzing the problem. http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/

Answer 3

You did not indicate whether your code is managed or unmanaged. Assuming he's uncontrollable. In the debugger:

 .symfix .reload ~*kb 

Browse the call stack for all threads and identify the thread that caused SO. It is easy to identify the stream with SO, because the call stack will be too long. Go to this stream with the command ~<N>s , where the stream number, drop more of the call stack with the k 200 command to drop up to 200 lines of the call stack. At the very bottom of the call stack, you should see the code that created the nested loop.

If your code is managed, use the SOS extension to drop calls.