1

When an exception was raised I created a mini dump for a .NET application with parameters

MiniDumpNormal | MiniDumpWithProcessThreadData | MiniDumpWithThreadInfo | MiniDumpWithUnloadedModules

which are required to extract the managed callstack (from What is minimum MINIDUMP_TYPE set to dump native C++ process that hosts .net component to be able to use !clrstack in windbg). The mini dump generation is executed in an exception filter as described here

When executing !dumpstack on the crash dump in WinDBG a can see something like

ChildEBP RetAddr  Caller,Callee
...
001dccc0 09b301a3 (MethodDesc 0x274268c +0x133 MyNameSpace.ErrorObject.FaultyMethod(Int32))
...

If I'm not mistaken this means that the error was generated at offset 0x133 in method FaultyMethod where 0x133 is the offset in the JIT compiled machine code.

How can I translate this offset back to the source code or IL line number to identify the instruction that caused the exception?

Community
  • 1
  • 1
Paul B.
  • 2,394
  • 27
  • 47

2 Answers2

1

Have you tried debugging it using the SOS.dll in windbg? You can use the CLRStack command to get a the managed code stack trace. See Unable to load SOS in WinDbg for instructions on loading it. However, as you say, dumpstack gives the instruction offset.

To convert the instruction offset, a clunky but workable way is to load the suspect assembly into ILDASM, drill down into the class and method/property and look at the IL. The instructions are preceded by IL_XXXX where XXXX is the hex offset from the start of the method. It will not give you the exact code but it will give you more information, particularly around method calls.

Community
  • 1
  • 1
akton
  • 14,148
  • 3
  • 43
  • 47
  • Yes, I am using SOS.dll (I think `!dumpstack` is an SOS command). `!clrstack` actually gives me less information as I can only see the method in the callstack but not the instruction offset. Unfortunately, parameters and locals are not available either since I cannot take I full memory dump (a first try created a 400MB file...) – Paul B. Sep 24 '12 at 12:01
  • @paulB Ah. I have always used the clrstack so I can get access to the locals and arguments. You learn something new everyday. Added note about ildasm to the answer. – akton Sep 24 '12 at 12:18
  • Thanks for your input! I just tried using ildasm and it seems a little tricky as the IL offset does not necessarily match the offset in the dump (which should be referring to the compiled machine code, I guess). I'll play around with windbg and ildasm some more and let you know about the results. – Paul B. Sep 24 '12 at 13:03
0

In case anyone is interested, here is my approach to the problem. It starts with adding MiniDumpWithIndirectlyReferencedMemory to the MiniDumpWriteDump call. That will lead to the inclusion of memory pages referenced by pointers on the stack. Although MSDN states "This option can increase the size of the minidump file significantly" in my tests the size of the mini dump file grew by no more than a few 100 KB.

Now the compiled machine code of the method that threw the exception is available in the dump. This means !u can be used in WinDBG/SOS to disassemble the code. While this is not exactly the IL or source code it should not be too hard to match the machine code instructions with the IL/source code. This blog post features an example how to do it.

Paul B.
  • 2,394
  • 27
  • 47