I am using visual c# to debug a large c# project. The project is very large and only some of the pdbs are build by myself. I can build all the pdb however it's very time consuming. I am debugging a backtrace but a part of the trace is marked with [External Code]. I know some pdb is missing, but how can I know which DLL the external code resides? In C I can get the EIP then see the process mapping to determine where the EIP lives, but how this can be done in .Net environment?
+2
A:
Go into Tools | Options | Debugging | General, and uncheck the "Enable Just My Code" checkbox. Now Visual Studio will show the full call stack (at least for managed code, you still may see some "native to managed transitions" in there).
itowlson
2009-12-16 07:17:04
oh yes, it shows the: [Native to Managed Transition] [Managed to Native Transition] But can I get where the transition goes?
Bin Chen
2009-12-16 08:19:49
I don't believe that's possible unless you have symbols (PDBs) for the unmanaged code. VS can do it for the managed parts of the stack trace because managed assemblies contain metadata, but unmanaged code doesn't have the same metadata so VS can't reconstruct the method calls. However you may be able to pin it down a bit using the Modules window and/or the "Show disassembly if source is not available" option -- but no experience of doing this, sorry.
itowlson
2009-12-16 08:31:45
Thanks. What I was doing before in Linux is I get the EIP(0x800453c like), then get a map of the dynamics DLL maps into, then I can get the DLL that the EIP fall into. Is it doable in Visual C#?
Bin Chen
2009-12-16 08:35:27
+1
A:
So if your project is really so big, than i asume that all your classes are well shared along your namespaces and that all the assemblies are named after the namespaces they contain. So if take a look where your external code begins (or ends) you should find out from (or to) where the call is going and determine the missing assembly pdb.
Oliver
2009-12-16 07:23:20
But then it's a problem of organization of the solution, project, assembly, namespace, class hierarchy. This to fix in retrospect is boring and expensive. So learn for the next project and implement a good structure at the beginning.
Oliver
2009-12-16 09:59:13
For now, just built all the pdbs (maybe overnight). This would be faster then just searching for a (maybe not existing) solution for days.
Oliver
2009-12-16 10:00:26