Cannot step into .NET framework source with VS2008 SP1

Question

Somehow my VS2008 SP1 has lost the ability to step into .NET framework sources. I've played around with checkboxes to no end; I've re-deleted the Symbol cache folder a dozen times; and I've tried all kinds of debug symbol servers.

All it does is download some .PDB files, but when I try to select a stack frame in .NET, I always get the message about no source available and "do you want to view disassembly".

What gives?

Added: Web application; Windows Vista Business x32; .NET 3.5 SP1.

Turnsole

Seems this feature is not yet very mature, I also experienced problems but then the other day it was working fine again... – Vertebra

Web application, Windows form, or service? – Flightless

check the updated link on my answer to see if I have captured the problem in my blog – Disorganization

I'm seeing exactly the same thing. – Skintight

For Visual Studio 2022 you can find the steps here – Visitor

Answer 1

I believe your problem is a mismatched version of .Net running on your System compared to the image version in the pdb that downloads from the symbol server. I've had the same problem on 64 bit Vista and Win7. I have yet to find a reference for how to get the assembly to 2.0.5.xxxx as indicated in the instructions. SP1 with all service packs on the two OSs I indacated are show the assemblies at 2.0.0.xxxx

EDIT: Start debugging any app you have and Hit CTRL+ALT+U to get the module list. It shows which assembly in the GAC is being used for the application

I blogged what I think is a better description of the problem. Blog of problem

Disorganization

How can I tell? The best I find are the file paths. For example, the .DLL is: C:\Windows\assembly\GAC_32\System.Web\2.0.0.0__b03f5f7f11d50a3a\System.Web.dll while the symbol path is: C:\Symbols\MicrosoftPublicSymbols\System.Web.pdb\64AF6E6A5B424405A87E37593541CC7F1\System.Web.pdb – Turnsole

Oh, and the "Version" column shows "2.0.50727.3074 (QFE.050727-3000)". Does this mean I'm getting the wrong symbol files? – Turnsole

yeah, you are version 2.0.50727.xxxx. I have that same version, except the xxxx part and I also can't use the symbols. It downloads them and acts like it attaches, but doesn't. The same config works fine on Vista 32 box. I'm just leaning towards it being a version issue between symbol and gac – Disorganization

Answer 2

When you enter debugging mode, open the Modules window, right click on the framework component and choose to load source from the Microsoft servers.

Lacedaemon

Isn't that the same as right-clicking a stack frame and telling it to load source from Microsoft servers? If so, then it doesn't work. But I'll try this suggestion tomorrow when I'm back at work. – Turnsole

Hmm... it worked for a standalone application, but not for the web application... – Turnsole

Doesn't the Microsoft server only return pdbs without source? – Disorganization

Answer 3

I was having problem that i cant step into to the Framework source code.

Then i went to project settings, and set Target Platform to "Any CPU", and then magic happened, by default Target Platform setting was "x86".

My platform Win7 x64, VS2010

Motorist

Interesting. Although at the time I posted this I had only a 32-bit OS, plus the setting has always been "Any CPU". But this is noteworthy. – Turnsole

Answer 4

I've run into this a few times in 2005. Much of this is voodoo and probably irrelevant, but somewhere in here is the answer (that works for me):

1. Kill the service
2. Delete any local .pdbs
3. Get rid of the temp files in (for example) C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files (either just the project-related files or all of them)
4. Restart service
5. If that didn't work, repeat 1-4, reboot and then try

Reasonless

Answer 5

I've noticed that if this issue occurs when you're running a website, enabling HTTP keep-alives in IIS can fix it.

Flightless

(I've never encountered the issue with forms or services unless it's an issue with the executed app not being in the same location as the debug source.) – Flightless

In IIS7 on Vista, as I gather from Google, this is enabled by default. (Not to mention darn difficult to change) – Turnsole

Answer 6

Try this instruction, I got everything works fine!

Mark

that instruction doesn't work on x64 installs that are patched to SP1 – Disorganization

That instruction is for non-SP1. And yes, before SP1 it worked. Now it doesn't. – Turnsole

Answer 7

I've encountered the same issue on different machines. I get it right now on Win7 x86 with .NET v2.0.50727 CLR (3.5sp1). The most quoated post doesn't help. Notice that "Microsoft Symbol Server" is NOT source server with .NET sources. It hosts PDBs without source info (non-indexed). For .NET sources we need indexed PDBs from "http://referencesource.microsoft.com/symbols" and enable source server support. But sometimes it stops working. I guess the issue with being unable to download indexed .net's PDBs (as mentioned earlier) is related to version conflicts.

I can say only this:

WinServer 2008 R2 3.5.30729.4926 - works

Win7 x86 3.5.30729.4918 - doens't work

What I mean by "doesn't work": try to "load from symbols path" (from Module or Stack windows, doesn't matter) and get dialog for choosing .pdb (positioned in e.g. C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.pdb ). That is VS can't download pdb for dll. Absolutly the same actions on WinSrv2008r2 makes VS download pdb and (if source server support is enabled) sources.

Metritis