views:

64

answers:

2

We have some issues on a farm server which crashes several times a day. None of us have experience in WinDbg but my coworker managed to create dumps using adsutil.vbs and now I'm analyzing the dump.

Loading the symbols etc I've managed to do - I've then read a bit and tried both !analyze -v and several other commands. Among them I used .exr -1 which gives me the following:

0:013> .exr -1
ExceptionAddress: 089644b9
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000

Somewhere in the !analyze dump I read some details about a Nullpointer-Exception occurring so that's my lead so far. Now I'm a bit stuck - having a reference to a memorylocation without knowing where to look next... What would you suggest I should do now?

+2  A: 

I would highly suggest starting with the WinDbg tutorials on this MSDN blog. There's about five of them in the sidebar under "debugging school". The links cover a lot of basic aspects of debugging .net apps.

Or you can jump right to the Hunting Exceptions with Windbg tutorial.

womp
The book "Debugging Microsoft .NET 2.0 Applications" by John Robbins is also an excellent resource - http://www.amazon.co.uk/Debugging-Microsoft-NET-2-0-Applications/dp/0735622027
Simon P Stevens
+1  A: 

Since you seem to be able to create a dump at will (given the server crashes quite often), what I would do is this:

  1. Create a full crash dump, if you don't have one yet. You can use AdPlus (found in the WinDbg lib) for that, just read the docs to see how.
  2. Debug the dump at your own development environment, either Visual Studio (if you have a recent version) or WinDbg itself, having all the source code available.

This way, you'll be able to see exactly what your code has been doing while it was trying to access the null pointer, including the full state of the process memory at the time of the crash, at the comfort of your own development environment.

WinDbg is a fantastic tool for production debugging, but when possible, I always prefer taking the dumps back home, where its much easier to do the analysis.

eran