Как отлаживать случайные сбои?

Question

у нас есть приложение winforms для настольных компьютеров dotnet 2.0, и оно кажется случайным сбоем. нет трассировки стека, журнала вентиляции или чего-либо еще. это просто исчезает.

Есть несколько теорий:

1. машина просто исчерпала ресурсы. некоторые люди говорят, что вы всегда получите исключение дескриптора окна или исключение gdi, но другие говорят, что это может просто вызвать сбои.

2. мы используем обертки вокруг неуправляемого кода для 2 модулей. исключения в любом из этих модулей могут вызывать такое поведение.

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

Answer 1

Лучше всего купить книгу Джона Роббинса "Отладка приложений Microsoft .NET 2.0" . Ваш вопрос может пойти гораздо глубже, чем у нас есть место для ввода здесь.

Answer 2

Звучит для меня так, как будто вам сначала нужно войти в систему - возможно, вы можете прикрепить с помощью PostSharp регистратор к вашим методам ( см. Log4PostSharp ). Это, конечно, сильно замедлит вас и создаст тонны сообщений. Но вы должны быть в состоянии сузить проблемный код вниз ... Прикрепите туда больше журналов - удалите другие. Может быть, вы можете провести стресс-тестирование этой части позже. Если подозрительные части достаточно малы, вы можете даже выполнить проверку кода там.
Я знаю, ваш вопрос был об отладке, но это тоже может быть подход.

Answer 3

Вы можете использовать Process Monitor из SysInternals (теперь часть Microsoft), отфильтрованного до того, что вы хотите отслеживать. Это даст вам хорошее место для начала. Просто начните с жесткого фокуса или убедитесь, что у вас достаточно места для файла журнала.

Answer 4

Запустите ваше приложение с файлами pdb и присоедините WinDbg, выполните команду run.
Когда происходит сбой WinDbg, остановите приложение.
Выполните эту команду для создания файла дампа:

.dump / ma c: \ myapp.dmp

вспомогательным инструментом анализа является ADPlus

Или попробуйте это:

Захват пользовательских дампов с помощью оповещения о производительности
Как использовать ADPlus для устранения неполадок, связанных с зависаниями и сбоями
Отладка на платформе Windows

Answer 5

Я согласен с Бойдски. Но я также предлагаю это предложение. Внимательно посмотрите на потоки, если вы делаете многопоточность. Однажды у меня была такая ошибка, на которую потребовалось много времени, чтобы разобраться, и на самом деле Джон позвонил по телефону, помогая ей. Оказалось, что неправильная обработка исключений с потоками.

Answer 6

В прошлом я имел такое поведение в первую очередь в связи с тем, что COM-объекты не были освобождены и / или возникали проблемы с потоками. Погрузитесь в предложения, которые вы уже получили, но я бы также посоветовал выяснить, правильно ли вы освобождаете неуправляемые объекты, чтобы они не пропускали память.

Answer 7

вы должны использовать глобальный обработчик исключений:
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx

Answer 8

Есть ли у вас блок try / catch вокруг вызова строки Application.Run, который запускает поток GUI? Если это не так, добавьте его и войдите в систему, чтобы сгенерировать все исключения.

Вы также можете записать событие Application.ThreadException и записать его в случае, если это даст вам еще несколько подсказок.