What's the difference between managed callstack and native callstack, why cannot resolve the symbol from managed callstack by dbghelp? can anyone tell me the basic reason?
When a native exe runs, windows maps the exe (and dll's) into memory using memory mapped files functionality (not that that matters). So when your program runs, you have a module address which is the base address that the native exe (or dll) image is loaded from (e.g. module address points to the first byte in the exe/dll file and so on). So when you have a address from a stack walk, you "know" what module the address is from based on the loaded module list as the address will be in a range one of the modules address ranges. It then knows the offset into the exe file (i.e. address - module address == offset into exe). dbhelp uses this address to find the module and then uses the offset into the exe to find the symbol (the pdb has a table of address ranges to symbols).
So this is how it works for a native running code.
Why you can't work for managed exe is because how managed code works.
Compiled managed code not native code, it's IL. A managed EXE is a small native wrapper around a IL assembly. The native wrapper is used to "start" the .net runtime and run the entry point in the IL assembly.
The .net runtime uses JIT to convert the IL to native code. It does this by allocating memory, generating the native code and marking the memory page as excutable, then jumping to it. So when these addresses show up in a stack walk, it's doesn't map to ANY loaded native module (as it doesn't). So you just see a address it can't map to any PDB file.
So to be able to map this unknown addresses to a managed symbol, you need to have:
So dbghelp is only for native symbol mapping and knows nothing about managed stack traces.
The managed stack traces of memory dumps (or live process memory) needs knowage / access to the internal managed runtime tables to be able to resolve the temporary executable memory pages to managed symbols.