2009-11-03 2 views
1

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

При подключении к проблемному процесса я вижу следующее сообщение перед любым стеки вызовов:

ПРЕДУПРЕЖДЕНИЕ: Stack расслабиться информацию, недоступную. Следующие фреймы могут быть неправильными.

Кадры на самом деле выглядят правильно при прикреплении непосредственно к процессу. Однако, когда я беру дамп этого файла, а затем открываю дамп в WinDbg на другом компьютере, один из стековых фреймов отличается (указанная выше ошибка также отображается). Это изначально имело недоумение продавца, поскольку путь кода казался невозможным ,

Я взял дамп с помощью:

.dump /ma filename.dmp 

Что бы вызвать такое несоответствие, и есть все, что я могу сделать, чтобы надежно анализировать стеки вызовов файла дампа в? Могут ли быть какие-либо другие искаженные данные, о которых я должен знать?

ответ

2

Звучит так, как будто у вас может быть несоответствие pdbs. Вы пробовали команды !chksym и !itoldyouso? например, см. the Bugslayer article

Еще одна вещь, которую стоит попробовать: !sym noisy, которая должна показать вам, какие файлы pdb загружаются.

Смотрите также MSDN blog

2

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

Команда SOS! Clrstack имеет необходимую информацию из CLR для отображения значимого стека (или, по крайней мере, без предупреждения). Если вы используете какую-либо из встроенных команд дампа, вы увидите это предупреждение для управляемого кода.

Предстоящая книга Advanced .NET Debugging содержит дополнительные сведения. См. http://advanceddotnetdebugging.com/

+0

Спасибо Брайан. Поэтому я должен ожидать этого предупреждения при отладке потоков, управляемых управляемым кодом в WinDbg? Хорошо знать, однако проблема, которую я вижу, заключается в том, что неуправляемый стек стека отличается при отладке локально по сравнению с отладкой файла дампа на другой машине. Спасибо за ссылку - я прочитаю. –

+0

Я понял, что вы отлаживали управляемый код из-за тега .NET. Вы увидите предупреждение, если вы сбросите собственный стек для потока с управляемым кодом, поскольку WinDbg не распознает управляемые вызовы. С помощью SOS вы получаете правильное управляемое представление и, следовательно, никаких предупреждений. Тем не менее, все же может оказаться полезным сбросить собственный стек, и в этом случае вам просто нужно игнорировать предупреждение. Что касается вашего другого вопроса: не могли бы вы подробно рассказать о том, как стеки отличаются между локальным отладочным и отладочным отладки. –

+0

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