Visual C# backtrace: how to know where [external code] resides?

Question

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?

Onomastics

Answer 1

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).

Condescension

oh yes, it shows the: [Native to Managed Transition] [Managed to Native Transition] But can I get where the transition goes? – Onomastics

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. – Condescension

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#? – Onomastics

thanks! I knew about this setting - but just did not know how this shows in the stack trace if enabled... – Isomerous

Answer 2

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.

Eozoic

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. – Eozoic

For now, just built all the pdbs (maybe overnight). This would be faster then just searching for a (maybe not existing) solution for days. – Eozoic