отладка — получите имя функции c ++ из нотации! DllRegisterServer + 0x3ebfa для решения головоломки «бесконечное ожидание в критической секции»
Я новичок в отладке с символами (когда нет доступа к машине тестирования).
Я уже предоставил клиенту сборку Debug с файлом .pdb, но по какой-то причине полученный мной дамп-файл не содержит записей, относящихся к моему .dll (хотя клиент настаивает на том, что там возникает проблема, в частности, зависание приложения). Отладочная сборка была сделана с VC ++ 2008 x86 (я также попробовал более старый VC ++ 6.0 без разницы).
Трассировка стека, которую предоставляет клиент, выглядит так
ChildEBP RetAddr 01ece854 773f8e44 ntdll! NtWaitForSingleObject + 0x15 01ece8b8 773f8d28 ntdll! RtlpWaitOnCriticalSection + 0x13e 01ece8e0 02a92003 ntdll! RtlEnterCriticalSection + 0x150 ПРЕДУПРЕЖДЕНИЕ. Информация о размотке стека недоступна. Следующие кадры могут быть неправильными. 01ece8f0 02a8b4fa MyDllName! DllRegisterServer + 0xbd2dc 01ece920 02a8b49e MyDllName! DllRegisterServer + 0xb67d3 01ece930 02a8746c MyDllName! DllRegisterServer + 0xb6777 01ece93c 029dc5ca MyDllName! DllRegisterServer + 0xb2745 01ece99c 02a819e4 MyDllName! DllRegisterServer + 0x78a3 01ecea80 02a09776 MyDllName! DllRegisterServer + 0xaccbd 01eceb00 02a32506 MyDllName! DllRegisterServer + 0x34a4f 01eceb58 029f44bf MyDllName! DllRegisterServer + 0x5d7df 01ececdc 029f5e20 MyDllName! DllRegisterServer + 0x1f798 01eceda0 029f76da MyDllName! DllRegisterServer + 0x210f9 01ecedf4 291fe0ce MyDllName! DllRegisterServer + 0x229b3 01ecee98 29365243 ClientAppName! Class.Method2 + 0x262 01eceeb8 293378d9 ClientAppName! Class.Method1 + 0x37
Но я не уверен, что все это значит. Означает ли DllRegisterServer + 0x229b3 «функцию с адресом + 229b3 по адресу DllRegisterServer в файле карты»?
В файле карты у меня есть что-то вроде
0002: 0006d720 _DllRegisterServer @ 0 10137720 f DllName.obj
Но когда я суммирую 229b3 и 6d720, у меня нет совпадений в файле карты для полученного значения.
И почему трассировка стека показывает DllRegisterServer в качестве адресной базы? Это не первый адрес в файле карты. Перед ним много функций, должны ли они иметь отрицательное смещение (кажется бессмысленным)?
Я думаю, что я понимаю, что чтение отладки неправильно, но не могу понять, что именно не так ..
Если бы я мог узнать имена функций, это позволило бы мне двигаться дальше.
Все становится еще сложнее, так как я не думаю, что в моем .DLL нет критических разделов, но клиент настаивает на том, что именно мой dll вызывает критический раздел и никогда не выходит. На данный момент я пока не знаю, как доказать, что он неправ (или, может быть, выяснить, что это действительно моя библиотека, которая каким-то образом косвенно делает это, может быть, сокеты Windows или DNS разрешают имя в IP-адрес где-то за кулисами) критические разделы).
Решение
Я предполагаю, что ваша DLL плохо себя ведет, и вы блокируете блокировку загрузчика.
См. «Еще одна причина не делать ничего страшного в DllMain: непреднамеренный тупик» Вот
Другие решения
Это недавнее сообщение в блоге Раймонда Чена — именно тот ответ, который вы ищете: Восстановление символов в трассировке стека, изначально созданной без символов.
По какой-то причине отладчик (или что-либо, производящее эту трассировку стека) не может найти символы отладки для вашего модуля, поэтому он делает все возможное, используя только таблицу экспорта DLL. Перефразируя Рэймонда:
Тьфу. Трассировка стека берется без рабочих символов. (Нет выбора
тотDllRegisterServerявляется глубоко рекурсивным 750 КБ функция. Просто
случайный осмотр, вы знаете, что символы неправильные.)Чтобы увидеть, как это исправить, нужно просто понять, что такое отладчик
делает, когда у него нет символов для работы: он использует символы из
таблица экспортируемых функций. Для каждого адреса, который он хочет разрешить, он
ищет ближайшую экспортируемую функцию, адрес которой меньше или
равно целевому значению.
Предполагая, что у вас есть правильный, соответствующий файл символов (.pdb) для версии DLL, которая сгенерировала трассировку стека, вы можете обмануть отладчик для загрузки DLL как будто это был дамп процесса, и тогда вы можете загрузить символы для него:
C:> ntsd -z MyDllName.dll
NTSD является Символьный отладчик Microsoft NT, который установлен по умолчанию во всех современных версиях Windows. Вы также можете использовать WinDbg, но я не уверен, есть ли способ использовать Visual Studio с этой техникой.
После того, как вы загрузили DLL в отладчик с символами, вы можете позволить отладчику выполнить тяжелую работу по декодированию трассировки стека. Смотрите сообщение в блоге для более подробных примеров этого.
detector