Отчет о сбоях, когда мое приложение блокируется на компьютере клиента

Question

Я работаю с несколько ненадежным (Qt / windows) приложением, частично написанным для нас третьей стороной (просто пытаюсь свалить вину). Их последняя версия более стабильна. Вроде, как бы, что-то вроде. Мы получаем меньше сообщений о сбоях, но мы получаем много сообщений о том, что он просто завис и никогда не возвращается. Обстоятельства различны, и из-за небольшого количества информации, которую мы можем собрать, мы не смогли воспроизвести проблемы.

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

• Как сторожевой таймер узнает, что процесс завис? Предположительно, мы даем приложению команду периодически говорить «все в порядке» сторожевому устройству, но куда мы помещаем это так, чтобы гарантировать, что оно будет происходить достаточно часто, но вряд ли будет на пути кода, на котором приложение заканчивается, когда оно заблокирован.

• Какую информацию должен сообщать сторожевой таймер при аварии? Windows имеет приличный API отладки, поэтому я уверен, что все интересные данные доступны, но я не уверен, что было бы полезно для отслеживания проблем.

Answer 1

Вам нужна комбинация мини-дампов (используйте DrWatson для их создания, если вы не хотите добавлять собственный код генерации мини-дампов) и userdump для запуска создания мини-дампов при зависании.

Особенность автоматического обнаружения зависания заключается в том, что трудно определить, когда что-то зависает, а когда оно просто замедляется или блокируется IO-ожиданием. Лично я предпочитаю, чтобы пользователь сознательно завершал работу приложения, когда он думал, что оно зависло. Помимо того, что это намного проще (мои приложения не склонны часто зависать, если вообще :)), это также помогает им «быть частью решения». Им это нравится.

Во-первых, ознакомьтесь с классической статьей , посвященной ошибкам , касающейся аварийных дампов и символов, в которой также содержится отличная информация о том, что происходит с этими вещами.

Во-вторых, получите userdump , который позволяет вам создавать дампы, и инструкции для его настройки для создания дампов

Когда у вас есть дамп, откройте его в WinDBG, и вы сможете проверить все состояние программы - включая потоки и стеки вызовов, регистры, память и параметры функций. Я думаю, что вам будет особенно интересно использовать команду « ~ * kp » в Windbg для получения стека вызовов каждого потока и команду «! Locks» для отображения всех объектов блокировки. Я думаю, вы обнаружите, что зависание будет происходить из-за тупиковой ситуации объектов синхронизации, которые будет трудно отследить, так как все потоки, как правило, ждут вызова WaitForSingleObject, но посмотрите вниз на стеки вызовов, чтобы увидеть потоки приложения (скорее чем «рамки», такие как фоновые уведомления и сетевые процедуры). После того, как вы сузили их, вы сможете увидеть, какие звонки были сделаны, возможно, добавив в приложение некоторые средства ведения журналов, чтобы попытаться предоставить вам дополнительную информацию, готовую к следующему провалу.

Удачи.

Ps. Быстрый гугл напомнил мне об этом: Отладка тупиков . (CDB - это эквивалент командной строки windbg)

Answer 2

Вы можете использовать ADPlus из средств отладки Microsoft для Windows, чтобы определить зависания. Он прикрепится к вашему процессу и создаст дамп (мини или полный) при зависании или сбое процесса.

WinDbg является переносимым, и его не нужно устанавливать (хотя вам необходимо настроить символы). Вы можете создать специальную установку, которая запустит ваше приложение с помощью пакета, который также запустит ADPlus после запуска вашего приложения (ADPlus - инструмент командной строки, поэтому вы должны быть в состоянии найти способ как-то его включить).

Кстати, если вы нашли способ распознать зависание внутри и смогли вызвать сбой процесса, вы можете зарегистрироваться в Отчеты об ошибках Windows , чтобы вам был отправлен дамп сбоя (если пользователь разрешает это).

Answer 3

Не заморачивайся со сторожевым псом. Подпишитесь на Microsoft Windows Reproting Error (winqual.microsoft.com). Они будут собирать трассировки стека для вас. На самом деле, вполне вероятно, что они уже делают это сегодня; они не поделятся ими, пока вы не зарегистрируетесь.

Answer 4

Я думаю, что отдельное приложение для отслеживания может вызвать больше проблем, чем решить. Вместо этого я бы предложил сначала создать обработчики для создания мини-дампов при сбое приложения, а затем добавить сторожевой поток в приложение, которое БЫСТРО вылетает, если приложение сходит с рельсов. Преимущество сторожевого таймера (по сравнению с другим приложением) заключается в том, что сторожевой таймер должен быть уверен, что приложение сорвалось с рельсов.

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

В CodeProject есть кое-что о MiniDumps , что может быть полезным примером. MSDN также имеет больше информации о них.