You need Source Files to do source-level debugging

I’ve had several people ask me “if my managed app and pdb are both in memory, can the managed debugger get the source from the debuggee’s memory too?”. This is a very reasonable question, but the answer here is “no”.

It comes up in different scenarios:

  • You can debug Reflection-Emit code and in-memory modules (eg, stuff from Assembly.Load(Byte[], Byte[]).
  • some highly dynamic languages (for example, JScript) let you create a function from a string. Thus there is no physical source file for that function.
  • you may have functions or snippets coming directly from user-input .  
  • you may want to get source from a previous build from a source-control system.

However, your source always needs to be some physical (not necessarily local) file. The symbol reader interfaces have some methods like “HasEmbeddedSource”, which may tempt you into thinking this functionality is available. I talked to Steve about this and he explained that they’re not fully operational.

Our suggested workaround is to create temporary files for the source.

Note that this is really entirely an issue on the debugger-side, not the platform side. The debugger retrieves the source files and shows them to the user. So a debugger author could come up with any arbitrary method to get source. The challenge is making it standard enough that enough debuggees cooperate such that it would be useful.


Comments (3)

  1. No idea if this was ever asked, but can source files be embedded into the pdb file?

  2. jmstall says:

    Great question: Steve ( is the authority here. I’m 99% sure the answer is "No" (despite what the API may lead you to believe) for the standard managed debugging scenarios.

    Technically, a PDB can store arbitrary information, and technically, a debugger is just an application that could pull a source file from anywhere, so technically, the answer is yes. But practically, the answer is no (since the PDB format is private, we don’t let managed compilers put source files in their today, and the symbol APIs don’t expose a way of getting those files out).

  3. I think this could prove a worthy feature to implement, giving that once generated, the pdb refers only to one specific version of an assembly and one specific set of source files.

    I remember we once tried to ‘pry open’ our pdb files to put the source in them, since it is so much easier than to try and keep a list of source files per assembly version…