All Replies

• Monday, June 29, 2009 2:39 AMRick ByersMSFT, Owner

   
  

  0

  Sign In to Vote
  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 paramsare 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

  • Marked As Answer byVipul Patel - CLRMSFT, ModeratorMonday, June 29, 2009 5:44 AM
  •  
  • Reply
  • Quote

   
• Monday, June 29, 2009 8:11 AMTokyoBrit

   
  

  0

  Sign In to Vote
  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 5worker 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.