Не удается загрузить символы Microsoft при запуске CDB в службе Windows

Question

У меня есть .NET служба Windows , которая вызывает cdb.exe для анализа аварийных дампов.Я хочу при необходимости автоматически загружать символы из http://msdl.microsoft.com, используя аргумент:

-y srv*c:\symbols*http://msdl.microsoft.com/download/symbols

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

Проблема в том, что когда я запускаю приложение в качестве службы Windows, символы не загружаются, и, если я включаю symnoisy, в выходной журнал cdb у меня есть запись для каждого символа, говорящая, что символ не имеетбыл найден по адресу http://msdl.microsoft.com

Итак, я проверил это с помощью сниффера, и забавно то, что при работе в качестве службы сервер символов Microsoft не выполняет никаких запросов.

Гуглил немного, я обнаружил, что я не единственный с этой проблемой, и кажется, что проблема в том, что при запуске приложения в качестве службы Windows, он используетБиблиотека winHTTP для http-запросов вместо wininet, которая, как мне кажется, является корнем проблемы : http://support.microsoft.com/kb/238425

Итак, я не знаю почему, cdb не может подключаться к символам msсервер использует библиотеку winHTTP, и мне нужен способ заставить cdb использовать wininet по умолчанию.

У кого-нибудь есть идея обойти эту проблему?

Answer 1

Полный ответ здесь: http://infopurge.tumblr.com/post/10438913681/how-does-cdb-access-the-microsoft-symbol-server

При запуске из командной строки cdb использует WinINet для доступа к интернет-ресурсам.При запуске из службы Windows cdb использует WinHTTP для доступа к интернет-ресурсам.

Для WinHTTP вам необходимо установить некоторые параметры реестра, чтобы остановить попытку использования прокси (bogusproxy) для доступа к серверу символов.

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

SET DBGHELP_WINHTTP=AnythingOtherThanEmpty

Чтобы отключить прокси WinHTTP дляДля cdb и symsrv необходимо указать один из следующих ключей в реестре:

Для x32-версии cdb, работающей на x32-битной машине из среды Windows Service.HKLM \ Software \ Microsoft \ Symbol Server \ NoInternetProxy DWORD 1.

Для x32-версии cdb, работающей на x32-битной машине из командной строки.HKEY_CURRENT_USER \ Software \ Microsoft \ Symbol Server \ NoInternetProxy DWORD 1.

Для 32-битной версии cdb, работающей на 64-битной машине из среды Windows Service.HKLM \ Software \ Wow6432Node \ Microsoft \ Symbol Server \ NoInternetProxy DWORD 1.

Для 32-битной версии cdb, работающей на 64-битной машине из командной строки.HKEY_CURRENT_USER \ Software \ Wow6432Node \ Microsoft \ Symbol Server \ NoInternetProxy DWORD 1.

Для x64-версии cdb, работающей на x64-битной машине из среды Windows Service.HKLM \ Software \ Microsoft \ Symbol Server \ NoInternetProxy DWORD 1.

Для 64-битной версии cdb, работающей на 64-битной машине из командной строки.HKEY_CURRENT_USER \ Программное обеспечение \ Microsoft \ Symbol Server \ NoInternetProxy DWORD 1.

Answer 2

Та же проблема возникает при запуске из планировщика задач. Я пробовал использовать разные аккаунты, но безрезультатно, пока не нашел этот пост.

Я запускаю CDB из скрипта Python (который выполняет всю «магию» в получении нужных предпосылок на месте) и для облегчения запуска Python я создал небольшой пакетный скрипт.

Добавление переменной среды, как описано в sekogan, решило проблему.

@echo off
setlocal
REM Forcing CDB to use WinInet instead of WinHTTP when running as a 
REM 'service' due to that WinHTTP uses some bogus proxy when not run from 
REM the console.
set DBGHELP_WININET=1

set PYTHONPATH=<your path>
call <path to venv>\Scripts\python.exe -m <script module> <params>

endlocal

Answer 3

Вы также можете сделать наоборот - заставить dbghelp.dll использовать WinInet вместо WinHTTP, добавив

DBGHELP_WININET=1

в системную среду.Это исправит проблему в cdb.exe и других инструментах, использующих dbghelp.dll, например, symchk.exe.