Following blog post has been written by EMEA Technical Lead Irfan Ahmed
You see the following Error message in the event logs and confused with the exception it shows. Event Type: ErrorEvent Source: .NET Runtime 2.0 Error ReportingEvent Category: NoneEvent ID: 5000Date: 10/29/2008Time: 2:10:36 PMUser: N/AComputer: NEWHRIS2Description:Event Type clr20r3, P1 1bgmfvseqkrpmf55nn2sg4ned1xmqtaz, P2 126.96.36.199, P3 47e3541a, P4 abc.exe, P5 188.8.131.52, P6 48577894, P7 18, P8 18, P9 ucpiekqexdxda0ooystximcos2bw1ngn, P10 NIL.Normally you feel its a .NET framework error but its not. it’s a problem with the application which threw this event log. In the above example its abc.exe (actual name changed) which was customer exe in my case. You are also confused with the exception message it shows as most of the time you see the exact exception like out of memory or invalid operation exception. Here is the explanation about the details showed in the event log.When the runtime creates Watson buckets, if the size exceeds a certain amount (in the two cases in your buckets below, 32 chars) then it will first try some intuitive truncations (e.g. remove “Exception” from the end of an exception type or “dll” from the end of an assembly) and if it’s still too long will hash (Sha1, I believe) and then Base32 encode the string. We also treat strings w/ Unicode chars specially (although that likely doesn’t apply in your case given the string I can read). Given that these transformations yield the same results for the same input, the bucket is still valuable as a way to uniquely identify the crash, but unfortunately illegible.
For reference the buckets for clr20r3 (managed) crash types are:
P1: App Name (32 char limit)P2: App Version (assembly version number)P3: Timestamp of the exeP4: Assembly Name (64 char limit)P5: Version of faulting assemblyP6: Timestamp of faulting moduleP7: MethodDef (after stripping off 06h high byte)P8: IL Offset of faulting instructionP9: Exception Type (32 char limit)