This project is read-only.

.NET 4.0 support for PDB rewriting

Topics: PDB Reader, PDB Writer
Dec 28, 2009 at 5:52 PM


I'm working on a postprocessor for assemblies. the .dll files are written fine, but the .pdb files are somehow not correct. If i attach a debugger to an executable, it tells me that the debugger is configured to debug .NET 1.1/2.0 assemblies, and the runtime is .net 4.

I'm not sure if this is a problem with the PDB reader or writer (or maybe it's both) so i choose both PDB reader and writer tags for this discussion.


Is this a known issue?



Matthijs ter Woord

Dec 28, 2009 at 6:08 PM

The issue is new to me, but I can imagine why it is happening. The PDB writer is still just a wrapper for a COM component supplied by the CLR. My guess is that the CLR v4 has updated this component to write out a new format expected by the v4 debugger.

I'll try and follow up with the debugger team. Since the issue has not come up before and people are rewriting v4 dlls and pdbs, it would be helpful to know more about your configuration. For example, did you rewrite the PDB file on a system that did not have CLR v4 installed on it?

Dec 28, 2009 at 6:19 PM

I'm going to try to send a sample (.zip) showing the project. The rewriter project itself is .net 4, and the rewriting occurs on a machine running vs2010.


I'll will follow up if i find a way to send the file..


Dec 28, 2009 at 6:23 PM

Sample project at

Jan 24, 2010 at 4:30 PM

Any news on this one? Does code contracts checker use an unmodified version of ccimetadata/cciast? If so, that one does not goof up my debug symbols...


Jan 24, 2010 at 6:25 PM

Sorry, this got buried under an avalanche of e-mail and I'm still digging my way out. I had asked someone to see if they could reproduce this and I think the answer was "no". The fact that the rewriter for the contract checker does not have a problem is suspicious. The contract rewriter uses an older version of CCI, but both that version and this version just use the same COM component to write out the PDB file.

One possibility is that the PDB is just fine, but that the executable is has been written out to target an earlier version of the CLR. Have a careful look at what ILDasm reports for the headers.