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

Question

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

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Это можно легко объединить с Microsoft Public Symbol Store, используя следующую начальную настройку:

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

А Магазин общедоступных символов Microsoft документировано как http://msdl.microsoft.com/download/symbols.

Answer 4

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

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

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