Блог

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

Я использую SymFunctionTableAccess64 для обратного вызова доступа к таблице функций, и обработчик символов был инициализирован с помощью SymInitialize(). Есть ли какая-то магия, которую мне нужно сделать в dbghelp, чтобы заставить его правильно перемещаться по управляемым фреймам?

Пример сбоя стека вызовов:

UnmanagedFrame1
UnmanagedFrame2
UnmanagedFrame3
ManagedFrame1 <----- (StackWalk64 fails after this frame)
ManagedFrame2
UnmanagedFrame4
UnmanagedFrame5
ntdll!RtlUserThreadStart

Примечание: этот вопрос НЕ касается того, как преобразовать управляемые фреймы в символы / имена методов / и т.д., я просто хочу обойти весь стек без учета разрешения символов / и т.д.

Кроме того, IDebugControl4::GetContextStackTrace работает корректно, но DbgEng использует обратный вызов таблицы пользовательских функций, а не просто делегирует SymFunctionTableAccess64 . Я подозреваю, что проблема в том, что среда CLR использует RtlInstallFunctionTableCallback для установки таблицы функций обратного вызова (которая указывает на mscordacwks), а SymFunctionTableAccess64 недостаточно умен, чтобы следовать этому.

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

Помогает ли вообще расширение SOS debugger? Он предоставляет возможность из windbg и Visual Studio перемещаться по стеку именно так, как вы хотите.

В качестве альтернативы некоторую пользу может принести использование стека профилировщика в .NET Framework 2.0: основы и не только.