Visual Studio loading symbols

Debug -> Delete All Breakpoints ( http://darrinbishop.com/blog/2010/06/sharepoint-2010-hangs-after-visual-studio-2010-f5-debugging ) After that you can use them again, but do it once. It will remove some kind of "invalid" breakpoints too and then loading symbols will be fast again. I was chasing this issue for days :(.

Another reason for slow loading is if you have disabled "Enable Just My Code" in Debugging options. To enable this go to:

Tools -> Options -> Debugging -> General -> Enable Just My Code (Managed Only) 

Make sure this is checked.

Configure in Tools, Options, Debugging, Symbols.

You can watch the output window (view, output) to see what it's doing usually. If it's really slow that probably means it's hitting a symbol server, probably Microsoft's, to download missing symbols. This takes three HTTP hits for each file it can't find on every startup - you can sometimes see this in the status bar at the bottom or in e.g. Fiddler. You can see which modules have loaded symbols in Debug, Windows, Modules whilst you're debugging.

Symbols mean you get useful stack trace information into third party and system assemblies. You definitely need them for your own code, but I think those get loaded regardless. Your best bet is to turn off any non-local symbol sources in that menu and, if you're loading lots of symbols for system assemblies that you don't need to debug into you can temporarily disable loading those to speed up debug start - but they're often useful to have loaded.

Just had this problem.

I fixed it by navigating to:

Tools -> Options -> Debugging -> Symbols

Then unchecking all non-local sources for Symbol file (.pdb) locations

e.g. Microsoft Symbol Servers and msdl.microsoft.com/download/symbols

I faced a similar problem. In my case I had set _NT_SYMBOL_PATH to download from Microsoft Servers for use in WinDbg and it looks like when set, Visual Studio will use that with no way to ignore it. Removing that environment variable resolved my issue.

You can try the following answer to Visual Studio debugging/loading very slow:

Go to Tools -> Options -> Debugging -> General CHECK the checkmark next to "Enable Just My Code". Go to Tools -> Options -> Debugging -> Symbols Click on the "..." button and create/select a new folder somewhere on your local computer to store cached symbols. I named mine "Symbol caching" and put it in Documents -> Visual Studio 2012. Click on "Load all symbols" and wait for the symbols to be downloaded from Microsoft's servers, which may take a while. Note that Load all symbols button is only available while debugging. UNCHECK the checkmark next to "Microsoft Symbol Servers" to prevent Visual Studio from remotely querying the Microsoft servers. Click "OK".

Also try to delete all the breakpoints(Debug>Delete all the breakpoints),

See Also: Visual Studio 2015 RC1 Hangs in Debug mode while loading symbols

For me, it seems related to breakpoints, as indicated in the accepted answer. However, I found two workarounds that did not involve deleting all the breakpoints:

Restarting Visual Studio seemed to fix it temporarily.

Clicking the "X" button to close Visual Studio while debugging causes the "Do you want to stop debugging?" message box to pop up; while this message box is up, the symbols load at ordinary speeds. Once all the symbols are loaded, you can click "No" to cancel the close.

Just encountered this issue. Deleting breakpoints didn't work, or at least not just on its own. After this failed I Went Tools > Options > Debugging > Symbols and "Empty Symbol Cache"

and then cleaned the solution and rebuilt.

Now seems to be working correctly. So if you try all the other things listed, and it still makes no differnce, these additional bits of info may help...

In my case Visual Studio was looking for 3rd-party PDBs in paths that, on my machine, referenced an optical drive. Without a disc in the tray it took about Windows about ~30 to fail, which in turn slowed down Visual Studio as it tried to load the PDBs from that location. More detail is available in my complete answer here: https://stackoverflow.com/a/17457581/85196

I had the same problem and even after turning the symbol loading off, the module loading in Visual Studio was terribly slow.

The solution was to turn off the antivirus software (in my case NOD32) or better yet, to add exceptions to it so that it ignores the paths from which your process is loading assemblies (in my case it is the GAC folder and the Temporary ASP.NET Files folder).

My 2 cents,

I was having a similar problem while trying to get a (Visual Studio 2013) Diagnostics Report in x64 Release Mode (CPU Sampling) and while the symbols for the needed dll files were loaded, the symbols for my executable would fail to load.

I didn't change anything in the Symbols menu, I instead made some changes within the Property Pages of my executable's thread in the Solution Explorer, namely

Configuration Properties / General / Enable Managed Incremental Build to YES

Configuration Properties / Debugging / Merge Environment to NO

Configuration Properties / C/C++ / Enable Browse Information to YES (/FR)

Configuration Properties / Linker / Enable Incremental Linking to YES (/INCREMENTAL)

EDIT : This last one does the trick

....

Configuration Properties / Linker / Debugging / Generate Debug Info to Yes (/DEBUG)

....

After that it worked and it loaded the symbols fine. I'm sure one or more of the above did the trick for me (although I'm not sure exactly which) and just want to let others know and try this..

peace

Try right clicking at one of the breakpoints, and then choose 'Location'. Then check the check box 'Allow the source code to different from the original version'

Visual Studio 2017 Debug symbol "speed-up" options, assuming you haven't gone crazy on option-customization already:

At Tools -> Options -> Debugging -> Symbols a. Enable the "Microsoft Symbol Server" option b. Click "Empty Symbol Cache" c. Set your symbol cache to an easy to find spot, like C:\dbg_symbols or %USERPROFILE%\dbg_symbols After re-running Debug, let it load all the symbols once, from start-to-end, or as much as reasonably possible.

1A and 2 are the most important steps. 1B and 1C are just helpful changes to help you keep track of your symbols.

After your app has loaded all the symbols at least once and debugging didn't prematurely terminate, those symbols should be quickly loaded the next time debug runs.

I've noticed that if I cancel a debug-run, I have to reload those symbols, as I'm guessing they're "cleaned" up if newly introduced and suddenly cancelled. I understand the core rationale for that kind of flow, but in this case it seems poorly thought out.

Unchecking "Enable JavaScript debugging for ASP.NET (Chrome and IE)" in Tools->Options->Debugging->General resolved my case with unavailability to launch VS2017 debugger with pre-set breakpoints.

The only thing that worked for me was changing the code type.

In the Attach to Process window, I changed the Attach to: selection to Automatically determine the type of code to debug, then my breakpoints were hit.

I previously had only Native code selected.

goto project properties -> debug -> uncheck enable native code debugging

I had a similar issue where visual studio keeps loading symbol and got stuck.

https://i.stack.imgur.com/fW1Vk.png

After I remove the extra parameter, it starts working again.