У меня проблема с приложением, которое мы сделали, которое иногда завершается с ошибкой StackOverflowException в некотором коде .NET.
К сожалению, приложение частично неуправляемое и частично управляемое, и по какой-то причине проблема проявляется только на компьютерах, не принадлежащих разработчикам.
Мой текущий план состоит в том, чтобы использовать WINDBG (часть средств отладки для Windows от Microsoft), установленную на компьютерах тестеров, и я могу заставить WINDBG перехватить создание рассматриваемого исключения.
Таким образом, я могу сделать следующее:
sxe ld:mscorlib g .loadby sos clr !stoponexception -create System.StackOverflowException g К сожалению, поскольку эта проблема возникает только через день и только после 50+ выполнений, я бы предпочел, чтобы тестировщикам приходилось вводить это полностью или частично при каждом запуске этого приложения.
Я попытался поместить вышеупомянутые команды в текстовый файл и создал ярлык для них следующим образом:
"...\windbg.exe" -c "$<c:\windbg.txt" -o "...\app.exe" Это запускает отладчик WINDBG, но, к сожалению, не с этим сообщением об ошибке:
0:000> sxe ld:mscorlib 0:000> g Command file caused an implicit wait Command file execution failed, HRESULT 0x80004005 "Unspecified error" Так что, видимо, gне допускается в таком скрипте запуска.
Можно ли делать то, что я хочу? Могу ли я автоматизировать это, или мне просто нужно подготовить пакетный файл или что-то, что использует autohotkey, который делает это?
Хотя уже поздно, но я все же хотел обойти это. Я столкнулся с той же проблемой, и наткнулся на этот вопрос в поисках ответа. Позже я нашел обходной путь.
Обходной путь - вызвать скрипт, используя $> <или $$> <или $$> a <, чтобы команды были объединены в один командный блок.
You could try .dump /ma /u c:\app.dmp so that you get a crash dump which can be copied and analyzed on your machine.
However, instead of trying to let the user run WinDbg on his machine, you can take a crash dump automatically using WER, copy it to your machine and then analyze without time pressure. See Collecting user-mode dumps to create settings in the Registry which store the dump on disk.
In both cases you should copy from C:\Windows\Microsoft.NET\Framework\v4.0.30319 (or Framework64):
Otherwise it might happen that your .NET version differs from his version and you can't analyze the bug.