Диагностика моего управляемого приложения .Net дает сбой правильно

Я дошел до того, что проекты, которые я писал, пробиваются в дикую природу (woo), и люди возвращаются с событиями сбоя приложений, которые я хочу исправить. Теперь я не могу сказать, что на компьютерах, на которых работают мои программы, есть доступные инструменты для разработки или диагностики, поэтому мой вопрос таков:

Из Проблемного события и всех его многочисленных сигнатурных подписок я уверен, что могу узнать метод вызова или причину возникновения этой ошибки, поскольку подписи выглядят как ссылки на, возможно, метод или такой.

Примером журнала, который я получил, является:

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

теперь некоторые вещи, которые я знаю:

Подпись 1 (мое имя приложения, revoloutionary, я мастер для этого)

Подпись 2 (моя версия приложения)

Подпись 4 (библиотека, из которой возникла ошибка)

Подпись 5 (эта версия библиотеки)

Подпись 9 (управляемая ошибка, которая была выбрана)

поэтому в основном все очевидные вещи, которые я могу решить. и все шестнадцатеричные значения, которые я не знаю, что с ними связано. Если мы возьмем эту ошибку в качестве нашего тестового примера, как мне определить, какая часть моего кода вызвала ошибку boo?

Любые атрибуты из msdn или других о том, что каждая сигнатура проблемы действительно относится, также могут быть полезными. (:

Это полный профиль.net 4.0. В любом учебнике, который дает мне ссылку на "mscorwks.dll", я вместо этого пишу "clr.dll". Еще не радость.

Изменение: я продвинулся дальше до точки, где windbg теперь загружает sos должным образом после выполнения программы. при запуске:

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

Редактирование 2: я продвинулся еще дальше до точки, где windbg теперь показывает мне токены в сборке. проблема в том, что ИЛ не существует... Возникает путаница. Чтобы заставить его работать, я запускаю приложение, обеспечиваю загрузку последних.pdb с помощью

!sym -noisy
.symfix
.reload -f

Затем я запускаю мой.loadby sos clr, который загружает модуль "sos" правильно сейчас. при запуске! token2ee mscorlib.dll 0600451e (дважды, спасибо dono), я верну это:

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

при запуске! dumpil 00007ffac34e1f40 логика диктует, что я должен найти IL_013c, но я этого не делаю, я получаю:

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

Это также приводит меня к тому, что я отлаживаю "неудавшийся модуль", который является библиотекой, упакованной в окна. и ИЛ, который возвращается, кажется, является внутренним метателем, который имел бы смысл в функции, называемой "WriteNotSupported()". Есть ли способ найти подпись метода, с которой столкнулась хост-сборка (.exe), чтобы вызвать сбой (или созданная функция, в которой произошел сбой, или... что-либо, относящееся к моей программе)