Debugging .dmp files from WinDbg in Visual Studio 2008 for .Net managed apps
I am trying to find how to take a crash dump of a .Net managed executable and then open the resulting .dmp file in Visual Studio 2008. I want to see where in the source code the exception is thrown, the call stack and the value of variables in functions on the stack.
To simplify the problem, I've written a mini-app that crashes:
...
class Program
{
static void Main(string[] args)
{
int a = 2; //Variable I want to see value for when debugging
if (!File.Exists(@"C:\Crasher\bin\Debug\file.txt")) //Doesn't exist
throw new FileNotFoundException(); //Unhandled exception thrown
}
}
...
I did a DEBUG build and ran it from outside Visual Studio. In windbg, I clicked "Attach to Process" and selected my app. Then I typed in the windbg command window:
.dump /ma C:\crasher\bin\debug\dump.dmp
Then I opened the .dmp file in Visual Studio. I went to Tools->Options->Debugging->Symbols and added the following:
http://msdl.microsoft.com/download/symbols (saved to local folder)
This gives me symbols for all of the DLLs listed in the Modules window (e.g. Kernel32.dll, gdi32.dll - I think all of them listed are native) with the exception of mscorlib.ni.dll. The Microsoft Symbol Server gives me symbols builds and .pdbs for mscorlib.dll but NOT mscorlib.ni.dll.
When I try to load the .pdb for my .exe itself, it tells me it does not match the app. I think this is because the .exe is managed and we don't yet have symbols for all of the native code beneath it - i.e. if I could get a symbols build and pdb for mscorlib.ni.dll this would work.
Is this reasoning correct? Am I missing something else?
Either way, why is mscorlib.ni.dll not available on the开发者_如何学C Microsoft Symbol Server, where can I get symbol information and is there anything else I should know for debugging managed code through crash dumps in Visual Studio.
Many thanks - any help will be appreciated.
Phil Whittington
As Jason Evans says in his comment, this is not supported in VS2008, but you can do it in WinDbg.
The easiest way to get a correct dump for a crash like this is to use adplus (which is included in Debugging Tools for Windows). There are various options, but to get a crash dump based on the process name, you could do
>adplus -crash -o c:\dumpdirectory -pn app.exe
This will give you two dumps. One for the first chance exception and one for the second. In this case they will be virtually identical, but for a more realistic scenario the first chance exception dump will show you the state of the application when the exception was thrown (i.e. before any exception handling occur). The second chance exception dump will show you the state of the unhandled exception.
To get the exception, open the crash dump and load SOS by typing .loadby sos mscorwks
.
Then use the !pe
command to print the exception on the current thread (which will be the faulting thread in this case). It will look something like this:
0:000> !pe
Exception object: 024a5114
Exception type: System.IO.FileNotFoundException
Message: Unable to find the specified file.
InnerException: <none>
StackTrace (generated):
SP IP Function
0020F0F0 005100D6 TestBench!TestBench.Program.Main()+0x66
StackTraceString: <none>
HResult: 80070002
To list the local variable a
use !clrstack -l
, but keep in mind that locals are rarely available in a release mode builds due to optimizations.
0:000> !clrstack -l
OS Thread Id: 0x1a50 (0)
ESP EIP
0020f04c 7571b727 [HelperMethodFrame: 0020f04c]
0020f0f0 005100d6 TestBench.Program.Main()
LOCALS:
0x0020f0fc = 0x00000002 <--- the value of a
0x0020f0f8 = 0x00000000
0020f328 51141b5c [GCFrame: 0020f328]
精彩评论