I’ve recently developed a major infrastructure that deals with serialization/de-serialization of complex application documents. One of the main challenges I had, was handling document files from another application. Although both source and consumer application share a common business library, there were also app-specific types serialized along with everything else. So to be able to correctly interpret the data being serialized and be able to act on every step, I had to inevitably delve into the framework 4.0 source code, mainly the ObjectManager.

The problem: It came to my understanding that there are a number of issues developers face when setting up framework debugging, despite the usual guides. The thing is, the guides are written to allow you to delve into framework code, but you need to understand that it only works out of the box for a given framework build version. Most of the times there’s a version mismatch between the source code version you’ve downloaded from the Microsoft Reference Servers, and the .Net Framework assembly versions you have installed on your computer. They’re both 4.0 (or 2.0 for that matter), but the build version differs a lot. So symbol loading fails on VS due to this. There is simply no updated pdb for the version you have installed.

All this to say there is one reason that is probably the root of most of the problems: Windows Update. This little bugger automatically downloads and installs newer versions of .Net Framework 2.0/4.0 assemblies in the context of a Security Update or regular feature update. Unfortunately, Microsoft doesn’t update the Symbol Servers at the same time, if ever, so when VS tries to find a pdb file for a given Framework assembly either locally or online, it is doomed to fail.

The fix: Either point your project references to older .Net Framework dll’s, or uninstall Windows updates. You can uninstall updates by going to Control Panel > Programs > Programs and Features > View Installed Updates, and removing everything under the Microsoft .Net Framework Client Profile or Microsoft .Net Framework Extended categories. You could check the Knowledge base article for each one of them to check if the specific .Net Framework assembly you wish to debug was changed. But that’s up to you.

Hope it helps.