Diagnosing my .Net managed application crashes correctly

Question

I've got to the point where projects i've been writing are making their way into the wild (woo) and people are coming back with application crash events that I want to fix. Now I cant garuntee that the PCs my programs are running on have any kind of development or diagnostics tools readily available on them so my question is thus:

From the Problem Event and all its many Problem Signatures, I'm sure I can find out the calling method, or what caused this error to occur as the signatures look like references to maybe a method or such.

An example of a log I have received is:

Problem signature:
  Problem Event Name:    CLR20r3
  Problem Signature 01:    SarkAgent.exe
  Problem Signature 02:    0.0.0.0
  Problem Signature 03:    509a4197
  Problem Signature 04:    mscorlib
  Problem Signature 05:    4.0.30319.34014
  Problem Signature 06:    52e0b679
  Problem Signature 07:    451e
  Problem Signature 08:    13c
  Problem Signature 09:    System.UnauthorizedAccess
  OS Version:    6.3.9600.2.0.0.256.48
  Locale ID:    2057
  Additional Information 1:    5861
  Additional Information 2:    5861822e1919d7c014bbb064c64908b2
  Additional Information 3:    d1d9
  Additional Information 4:    d1d94a13d3609d6b740644c12508f581

now some things I know are:

Signature 1 (my application name, revoloutionary, I am a wizard for working that out)

Signature 2 (my application version)

Signature 4 (the library that the error originated from)

Signature 5 (that librarys version)

Signature 9 (the managed error that was thrown)

so basically all the obvious stuff I can work out. and all the hex values I dont know what relates to what. If we take this error as our test case, how do I work out what part of my code has caused the boo boo?

Any paraphernalia from msdn or other about what each problem signature actually relates to would also be mighty useful as well. (:

This is a .net 4.0 Full Profile framework. On any tutorial that gives me a reference to "mscorwks.dll" i instead write "clr.dll" Still no joy.

Edit: I've progressed further to a point where windbg is now loading sos properly after program execution. when running this:

0:005> !token2ee mscorlib 0600451e
c0000005 Exception in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.token2ee debugger extension.
  PC: 00007ffa`c7a50c05  VA: 00000000`00000000  R/W: 0  Parameter: 00000000`00000000

Edit 2: I've progressed even further to a point where windbg is now showing me token relations within the assembly. the problem is the IL does not exist... Confusion ensues. To get it to work, I launch the application, ensure the latest .pdb downloads with

!sym -noisy
.symfix
.reload -f

I then run my .loadby sos clr which loads the module "sos" correctly now. when running !token2ee mscorlib.dll 0600451e (twice, thank you dono) i get this back:

Module:      00007ffac32e1000
Assembly:    mscorlib.dll
Token:       000000000600451e
MethodDesc:  00007ffac34e1f40
Name:        System.IO.__Error.WriteNotSupported()
JITTED Code Address: 00007ffac3fb8150

when running !dumpil 00007ffac34e1f40 logic dictates that i should find IL_013c but I do not, I get:

ilAddr = 00007ffac3a545f7
IL_0000: ldstr "NotSupported_UnwritableStream"
IL_0005: call System.Environment::GetResourceString
IL_000a: newobj System.NotSupportedException::.ctor
IL_000f: throw 

This also brings me onto a point now that I am debugging the "failed module" which is a windows packaged library. and the IL that is returned seems to be the internal thrower which would make sense on a function called "WriteNotSupported()". Is there any way I can find the method signature that the host assembly (the .exe) ran to cause the failure (or the created function that the failure resided in, or... anything relating to my program)

Answer 1

在MSDN博客上查看此帖子： Windows错误报告和CLR集成