Как отладить сбой BSOD, вызванный косвенно приложением .NET - PullRequest
4 голосов
/ 20 января 2012

У нас есть приложение .NET, которое передает файлы с клиентской рабочей станции в базу данных на центральном сервере в локальной сети.Несколько наших клиентов используют это на беспроводных рабочих станциях с Windows XP, которые используют коммерческий сторонний механизм шифрования WiFi (по разным причинам они не используют стандартное шифрование WiFi, такое как WPA).Довольно справедливо, что эти рабочие станции имеют синий экран при запуске нашего приложения.

Наше приложение не вызывает напрямую какой-либо неуправляемый код, но, очевидно, что наша программа косвенно вызывает проблему в базовом сетевом стеке.Я получил мини-файл дампа ядра с одной из уязвимых машин и загрузил его в WinDbg, и он сказал мне, что сбой, вероятно, был вызван файлом .sys, который является одним из файлов драйверов для программного обеспечения для шифрования (о котором я уже подозревал).Тем не менее, отладчик не сказал мне больше, что было полезно.

Мой вопрос таков: есть ли какой-нибудь способ для меня получить трассировку стека от момента сбоя до самого конца?в наше приложение .NET? Нужен ли полный дамп памяти?У меня есть источник для нашего приложения, но мне мешает тот факт, что: а) у меня нет источника или символов для рассматриваемого драйвера;и б) я не имею опыта отладки Windows на низком уровне.Я не против изменить наше приложение, если это необходимо, чтобы избежать проблемных вызовов, если это необходимо, но мне нужно знать, какие вызовы следует избегать.

Ответы [ 2 ]

3 голосов
/ 21 января 2012

Как отмечается в комментариях, программа пользовательского режима не может вызывать синий экран.Только компонент уровня ядра может вызвать BSOD.Наиболее вероятно, что ваша программа отправляет данные определенным образом, который сетевой драйвер не может обработать, и это вызывает BSOD.Это не ошибка ваших программ.ВСЕ драйверы ядра должны использовать защитные методы программирования.Так что, если происходит BSOD, это ошибка драйверов.Это одна из основных особенностей разделения kerenel / usermode.Пользовательский режим не должен делать что-либо, что может BSOD.

Я понимаю, что приведенный выше совет не всегда полезен, когда вы просто пытаетесь решить проблему.Поэтому лучше всего открыть дамп в windbg и запустить! Analyse -v.Это даст вам разумную трассировку стека (для неуправляемого кода), и вы сможете увидеть, какой драйвер вызывает проблему.

Если вы хотите увидеть, какой поток вызвал проблему, я боюсь, что ваш SOL.По сути, невозможно точно определить, какой поток вызвал проблему, поскольку, скорее всего, пакет был помещен в очередь, а затем обработан позднее.К тому моменту, когда окно BSOD укажет, что поток, помещающий пакет в очередь, уже отключился и занялся другими делами.

Но если вам очень повезло, и все звезды соединились, то, возможно, у вас может бытьпоток все еще находится в том же месте, в котором он помещал пакет в очередь, и вы можете увидеть, используете ли windbg с dll SOS.

Разумный помощник для начала работы с управляемой отладкой с помощью windbg находится здесь: http://blogs.msdn.com/b/alejacma/archive/2009/07/07/managed-debugging-with-windbg-introduction-and-index.aspx

Это не ответит на все ваши вопросы, но это неплохое начало, и поиск в Google поможет вам большую часть оставшегося пути.

0 голосов
/ 21 января 2012

Обычно это приводит к созданию файла дампа.Загрузите файл дампа в windbg, запустите «analysis -v» и загрузите соответствующий вывод для дальнейшего анализа.

...