Я пытаюсь обработать стек вызовов, который содержит как управляемые, так и собственные кадры процесса 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, но это получилось довольно схематично и в действительности не работало.