views:

1354

answers:

6

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.

+1  A: 

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

Chris Thompson
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.
Vilx-
Hmm... it worked for a standalone application, but not for the web application...
Vilx-
Doesn't the Microsoft server only return pdbs without source?
jmcecil
A: 

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
Tom
Nop, don't work. :( Was a good try though. :P
Vilx-
A: 

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

alord1689
(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.)
alord1689
In IIS7 on Vista, as I gather from Google, this is enabled by default. (Not to mention darn difficult to change)
Vilx-
+1  A: 

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

jmcecil
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.dllwhile the symbol path is:C:\Symbols\MicrosoftPublicSymbols\System.Web.pdb\64AF6E6A5B424405A87E37593541CC7F1\System.Web.pdb
Vilx-
Oh, and the "Version" column shows "2.0.50727.3074 (QFE.050727-3000)". Does this mean I'm getting the wrong symbol files?
Vilx-
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
jmcecil
A: 

Try this instruction, I got everything works fine!

abatishchev
that instruction doesn't work on x64 installs that are patched to SP1
jmcecil
That instruction is for non-SP1. And yes, before SP1 it worked. Now it doesn't.
Vilx-
A: 

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.

Shrike