Slow symbol loading in an ASP.NET Project in VS2012

Question

I'm having an issue with loading symbols on my ASP.NET MVC project. The first time I load visual studio and debug my project, symbols are loaded in roughly 2 seconds. I then end the debug session, make a code modification, and debug again, and the symbol load time is about a minute. Based on the research I have done, here are some applicable settings on my machine/VS:

In Options/Debugging/Symbols/Symbol file locations, "Microsoft Symbol Servers" is unchecked, and there are no additional locations.

Options/Debugging/Symbols/Cache symbols in this directory is "G:\Symbol Cache". I did click "Load all symbols" and I have inspected that directory and I see lots of symbols.

Just my code is enabled.

The _NT_SYMBOL_PATH and _NT_ALT_SYMBOL_PATH environment variables are not defined on my machine.

Options/Debugging/Symbols/Automatically load symbols for is set to "Only specified modules", with no modules specified.

I have tried both debug and release builds, with identical results. Ctrl + F5 loads the site almost immediately.

Summarize

I'm experiencing this problem as well and I hope someone come up with an answer... – Wellordered

I "fixed" the issue by uninstalling VS2012 and all dependencies, deleting the VS2012 folder in program files, re-installing VS2012, and caching all MS symbols from the symbol server (options -> debugging -> symbols). Best of luck to you. – Summarize

wow, solution by user961969 will only take couple of hours :) – Haematocele

Answer 1

I too had this problem, the cause was that I had accidently enabled the "Microsoft Symbol Server"

You can disable it by going to Tools > Options > Debugging > Symbols and uncheck the "Microsoft Symbol Server"

Now it loads just as fast as it used to.

Urina

Answer 2

I too had this problem and noticed that it was mostly related to 3rd-party assemblies acquired via NuGet. In these cases, Visual Studio was trying to load PDBs from paths that apparently existed on the original author's machine (i.e. D:\OriginalAuthor\MyVisualStudioProjects\AwesomeNuGetPackage) but on my machine the same path referred to an optical drive. I then discovered via Command Prompt that if you tried to change directory to an optical drive that didn't have a disc in the tray, it took a very long time (~30 seconds) to fail. With this in mind, my solution was to simply place a DVD in the tray. At that point Visual Studio was able to very quickly determine that the path didn't exist, skip loading the PDB, and go straight into debug.

So, if Visual Studio is taking a long time to load symbols, watch the Output window for the paths it's trying to access and verify that you can quickly access (or quickly fail to access) those paths yourself via Command Prompt.

This brings up an interesting question about security/privacy--apparently Visual Studio is storing the absolute path of the original PBD within the assembly. I suppose this isn't a super critical issue, but from a privacy perspective I don't really want my absolute filesystem paths being exposed to the public without my knowledge.

Menarche

Hahaha... "to fix my problem debugging in Visual Studio, I put a DVD in the tray". +1, this made my day :) – Hooves

FWIW, it looks like you can prevent VS from trying to load symbols for specific DLLs under Tools -> Options -> Debugging -> Symbols, then click on "Specify excluded modules". – Hooves

I don't know why but the exact opposite worked for me. I took an unrelated DVD out. – Behead

This NuGet and PDB is completely lame comparing to the fast and comfortable Java + Maven solution. – Folk

Answer 3

Just try this Debug -> Delete All Breakpoints. Its works on me.

Thisbe

Answer 4

I had 2 .dll's giving me grief that I didn't need to debug that started taking minutes to load. The afore mentioned solutions didn't help. So I went to Options -> Debugging -> Symbols and under the radio button for "All modules, unless excluded" click on "Specify excluded modules" link. Then type the .dll's that are causing issues.

Nyhagen