Finding method for error-reporting bucket parameters

Question

Hello Rick,

Came to this thread after digging into a clr20r3 event, as P7 and P8 give the MethodDef and IL Offset, so was looking for how to match those with my source code.

I have the PDB, so am able to open the DLL in ILDASM. It shows my assembly and it's 11 classes, and the numerous methods that those classes have.

The stastics show that I have 158 MethodDefs (8 abstract, 150 bodies), however I've not been able to find a way to match the identified MethodDef in the event message (a) with an actual method in my assembly.

Unless... When I Show the entire metadata, I do see the Methods listed, and they each have a unique number like (060000xx), so possibly 0600000a is the method in question.

Answer 1

Hi,
Usually the best way to find the source of a crash from an error-report is to download and open the minidump in WinDbg+SOS - you should see it in the output of !printException.  Using the bucket parameters to identify the source of a crash can sometimes be handy but is inherently limited (eg. once you find the throw point, next you may want to know where it was called, eg. because the problem is actually with an argument that was passed).  The bucket params are really designed just to separate distinct bugs into (roughly) distinct buckets.

That said, if there's some problem getting the minidump etc. and you'd still like to track down the source from the bucket params, then it should be possible (just a little bit of work).  Using ILDasm the easiest way is probably to use View -> Metainfo -> Show (without any of the 'Raw' options).  Then you can just search for the methodDef token from the event (060000xx), and then look down to see the MethodName and up to find the TypeDefName it's part of.  Then you can disassembly that method with source-line info turned on to correlate the IL offset to the source.

I hope this helps,
   Rick

Answer 2

Absolutely right. It was how I thought, and you verified. ILDASM showed this for the MethodDef 'a' and IL Offset of '4a':

.method /*0600000A*/ public hidebysig specialname 


...

  .line 52,52 : 21,22 ''
  IL_004a:  /* 00   |                  */ nop

And line 52 in my source code was:

    throw new System.Exception("Null object in session");

Which matched the "system.exception" that was the P9 value in the event.

Personally, I found using the tool to be very easy, once I could figure out how to match methods to the bucket parameter. Not sure if I could ever find the minidump, since this is a random event... That is, it has occured 451 times on different occasions over the last 11 months.

The bigger issue was that I probably would never have known that this exception was occuring except for the fact that unhandled exceptions in .NET 2.0 cause the worker process to stop, and that the default settings for IIS 6 causes the Application Pool to be disabled if there are 5 worker process failures within 5 minutes.

A disabled AppPool occured 5 times in the same 11 month period. Again, with no rhyme or reason, and no real way for me to know what the .NET web app was doing prior to the event being registered.

Answer 3

Great, glad you figured it out!  Yes, error-reporting can be great for tracking down strange random errors like this (primarily in client applications running on arbitrary computers, it's not really designed for the ASP.Net sceario but can be helpful in cases like this).

Rick