stackwalk / callstack and symbol resolve of managed and unmanaged code - dbghelp, etc.

[asanford]

We use StackWalk(StackWalk64) from dbghelp.dll to walk our
callstacksas needed, using the various Sym* methods
(SymGetSymFromAddr, SymGetLineFromAddr) to resolve source file,
function name, and source line number for each frame. This works fine
for unmanaged code, but when we have a call stack that goes into or
through some managed code, we cannot resolve any info for the managed
frames - we can however, get all the information for the unmanaged
frames in the stack, both before and after the managed frames.

Is there a way to get the dbghelp functions to resolve the managed
frame info? I tried all the latest dbghelp versions, up thru 6.3.5.1,
and it still doesn't work. It looks like 6.1 added a new method
SymFromToken that supports managed code, but what about supporting
managed code with the other methods? For the exact same callstack
that dbghelp cannot resolve info for, the debugger in visual
studio.net CAN resolve info for (if set for Mixed-mode debugging). Is
this because VS.net uses DIA instead of, or in addition to, dbghelp?
Will microsoft ever add full support for managed code in dbghelp? Is
there some other way to get this info? I know I can get a managed
call stack from within managed code by using the stacktrace classes,
but in some cases, this isn't practical - such as in an app that has
both managed and unmanaged code creating threads - unhandled
exceptions that occur in the unmanaged threads, perhaps once the
thread has travelled thru managed code to get to the point causing the
exception, are not readily catchable in managed code (we end up
catching them in the uhe handler specified via Win32). So at this
point, we have a call stack that has both managed and unmanaged.
Ideas?

So, will the Sym* (dbghelp) be supported for managed?
Do I need to use DIA?
What about IDebug* interfaces (from the "debugger engine" stuff from
"Debugging tools for windows")?
What about ICorDebug* (from the CLR)?

we already re-wrote our stackwalker once (to go manual debug info
walking to using dbghelp); do we now need to re-write again? If so,
to what? Will it change?

thanks for any help!

[asanford]

any help from Microsoft on this one

----- asanford wrote: ----

We use StackWalk(StackWalk64) from dbghelp.dll to walk ou
callstacksas needed, using the various Sym* method
(SymGetSymFromAddr, SymGetLineFromAddr) to resolve source file
function name, and source line number for each frame. This works fin
for unmanaged code, but when we have a call stack that goes into o
through some managed code, we cannot resolve any info for the manage
frames - we can however, get all the information for the unmanage
frames in the stack, both before and after the managed frames

Is there a way to get the dbghelp functions to resolve the manage
frame info? I tried all the latest dbghelp versions, up thru 6.3.5.1
and it still doesn't work. It looks like 6.1 added a new metho
SymFromToken that supports managed code, but what about supportin
managed code with the other methods? For the exact same callstac
that dbghelp cannot resolve info for, the debugger in visua
studio.net CAN resolve info for (if set for Mixed-mode debugging). I
this because VS.net uses DIA instead of, or in addition to, dbghelp?
Will microsoft ever add full support for managed code in dbghelp? I
there some other way to get this info? I know I can get a manage
call stack from within managed code by using the stacktrace classes
but in some cases, this isn't practical - such as in an app that ha
both managed and unmanaged code creating threads - unhandle
exceptions that occur in the unmanaged threads, perhaps once th
thread has travelled thru managed code to get to the point causing th
exception, are not readily catchable in managed code (we end u
catching them in the uhe handler specified via Win32). So at thi
point, we have a call stack that has both managed and unmanaged.
Ideas

So, will the Sym* (dbghelp) be supported for managed
Do I need to use DIA
What about IDebug* interfaces (from the "debugger engine" stuff fro
"Debugging tools for windows")
What about ICorDebug* (from the CLR)

we already re-wrote our stackwalker once (to go manual debug inf
walking to using dbghelp); do we now need to re-write again? If so
to what? Will it change

thanks for any help

[Habib Heydarian [MSFT]]

To create mixed (managed and native) call stacks, you need to use both
ICorDebug* and DIA, then do post processing to interleave the frames
correctly. You can resolve managed call stacks with ICorDebug* from
cordebug.h and IMetaData* from cor.h. EnumerateChains on ICorDebugThread is
a starting point.

HabibH.

"asanford" <an*******@discussions.microsoft.com> wrote in message
news:99**********************************@microsof t.com...

any help from Microsoft on this one?

----- asanford wrote: -----

We use StackWalk(StackWalk64) from dbghelp.dll to walk our
callstacksas needed, using the various Sym* methods
(SymGetSymFromAddr, SymGetLineFromAddr) to resolve source file,
function name, and source line number for each frame. This works fine for unmanaged code, but when we have a call stack that goes into or
through some managed code, we cannot resolve any info for the managed
frames - we can however, get all the information for the unmanaged
frames in the stack, both before and after the managed frames.

Is there a way to get the dbghelp functions to resolve the managed
frame info? I tried all the latest dbghelp versions, up thru 6.3.5.1, and it still doesn't work. It looks like 6.1 added a new method
SymFromToken that supports managed code, but what about supporting
managed code with the other methods? For the exact same callstack
that dbghelp cannot resolve info for, the debugger in visual
studio.net CAN resolve info for (if set for Mixed-mode debugging). Is this because VS.net uses DIA instead of, or in addition to, dbghelp?
Will microsoft ever add full support for managed code in dbghelp? Is
there some other way to get this info? I know I can get a managed
call stack from within managed code by using the stacktrace classes,
but in some cases, this isn't practical - such as in an app that has
both managed and unmanaged code creating threads - unhandled
exceptions that occur in the unmanaged threads, perhaps once the
thread has travelled thru managed code to get to the point causing the exception, are not readily catchable in managed code (we end up
catching them in the uhe handler specified via Win32). So at this
point, we have a call stack that has both managed and unmanaged.
Ideas?

So, will the Sym* (dbghelp) be supported for managed?
Do I need to use DIA?
What about IDebug* interfaces (from the "debugger engine" stuff from
"Debugging tools for windows")?
What about ICorDebug* (from the CLR)?

we already re-wrote our stackwalker once (to go manual debug info
walking to using dbghelp); do we now need to re-write again? If so,
to what? Will it change?

thanks for any help!