Посмертная отладка аварийного дампа без точной версии DLL-библиотеки Windows на сервере символов

Question

В моем приложении я использую функцию MiniDumpWriteDump (см. Dbghelp.dll) для записи файла аварийного дампа при каждом сбое моего приложения.

Я также использую сервер символов для хранения всех своих исполняемых файлов и файлов pdb, поэтому, когда клиент отправляет мне файл аварийного дампа, отладчик автоматически выбирает правильную версию исполняемого файла и информацию об отладке.

Я также храню DLL-файлы Windows (ntdll.dll, kernel32.dll, ...) и их отладочную информацию на сервере символов (используя SymChk). Отладочная информация берется с общедоступного сервера символов Microsoft.

В большинстве случаев это работает идеально, за исключением случаев, когда:

• клиент падает в одной из библиотек Windows
• и клиент использует библиотеки DLL, которые я не поместил на сервер символов

Это связано с тем, что хранить все варианты каждой DLL-библиотеки Windows на сервере символов (особенно с еженедельными исправлениями) весьма невозможно.

Так что, если клиент падает, скажем, в версии 5.2.123.456 NTDLL.DLL, и я не поместил эту точную версию DLL на моем Symbol Server, я застрял. Даже общедоступный сервер символов Microsoft не помогает, потому что он предоставляет только отладочную информацию, а не саму DLL.

Мое текущее решение - спросить у клиента его DLL, но это не всегда легко. Поэтому я ищу лучшее решение.

Есть ли способ получить отладчик, показывающий правильный стек вызовов, или загрузить отладочную информацию конкретной библиотеки DLL, даже если у вас нет точной версии библиотеки DLL?

В качестве альтернативы, есть ли способ получить все версии всех (или важных) Windows DLL (от Microsoft)?

EDIT:

А пока я нашел очень простой способ решить эту проблему. С помощью утилиты ModuleRescue (см. http://www.debuginfo.com/tools/modulerescue.html) вы можете генерировать фиктивные DLL из файла мини-дампов. С этими фиктивными DLL отладчик удовлетворяется и корректно начинает загрузку символов отладки с серверов Microsoft.

Answer 1

Можно ослабить разрешение символов WinDbg; см. мой ответ на аналогичный вопрос. С другой стороны, решение, которое я предлагаю здесь, основано на том факте, что библиотеки DLL идентичны , за исключением того, что разные GUID идентифицируют их символы отладки. Другая версия DLL, вероятно, будет иметь другой двоичный файл, поэтому символы, вероятно, не будут соответствовать должным образом, даже если вы можете заставить их загружаться.

Answer 2

Вы можете иметь несколько серверов символов на вашем пути символов. Поэтому просто установите путь к символам, чтобы он указывал на ваш собственный сервер для ваших личных модулей и на общедоступный сервер MS для модулей ОС, см. Путь символа :

Это можно легко комбинировать с Microsoft хранилище общедоступных символов с помощью следующая начальная настройка:

_NT_SYMBOL_PATH=srv*c:\mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:\mysymbols

* * * * * * * * * * * * * * * * * * * * * 1015 *.

Answer 3

Я почти уверен, что сервер символов Microsoft также предоставляет двоичные файлы. Я просматриваю свой магазин и вижу тонну файлов Microsoft .dll. Мой _NT_SYMBOL_PATH определен как

SRV*F:\Symbols\Microsoft*http://msdl.microsoft.com/download/symbols

Таким образом, он будет сначала искать в моем локальном хранилище, прежде чем пытаться скопировать их с публичного сервера Microsoft.

Answer 4

? Какая часть не работает?

Я никогда не был в вашей ситуации, но я ожидал, что отладчик выдаст вам правильную часть стека вызовов, которая была в вашем коде, вплоть до вызова в тёмную dll. Конечно, с этого момента и до фактического сбоя символы будут недоступны, но разве вы не видите, какой API NTDLL вызывался и какие аргументы были переданы этому вызову?

Вы не говорите, какой инструмент используете для отладки мини-дампов: WinDBG или VS.