Visual Studio loading symbols

Question

I'm working on a ColdFusion project for a while now, and Visual Studio started to behave strange for me at least.

I observed that when I started debugging, it built the project, it started the deploy, and the deploy finished and it was starting to load symbols for my project.

But it was very slow, and I don't know why it started to do this step. What may I have done?

Is this symbol loading step necessary? How can I disable it?

In the Tools -> Options -> Debugging -> Symbols dialog there is no Symbol file (.pdb) location added. And I pointed in my project's debug directory at the field below, and I checked the "Search the above directory only when symbols are ...." checkbox. How should I set up this dialog to turn off symbol loading?

I looked in the Modules window which symbols are loaded, but it says nothing to me. What is the problem?

Tarkany

I have tried every answer in the thread with no luck. – Training

Ussualy the symbols should be cached and should take little to no time to load, the only time you will notice symbol loading being slow is if the symbols are loading from microsoft symbol servers which is very very slow e.g ( not always very slow but slow none the less), so one good way to try and atempt to fix this problem is to delete the symbols cache, just go to the Debug -> Options -> Debugging -> Symbols and click the empty symbols cache, if this doesn't work could be another problem entirely, hope this benefits someone seeing as the question is 3 years old (: – Saucer

Note: If anyone continues to have trouble with debug symbols loading, try deleting your .vs folder. That worked for me. – Footboard

Answer 1

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 :(.

Vacillating

Visual Web Developer 2010 Express users can press CTRL+SHIFT+F9 and a prompt "Do you want to delete all breakpoints?" will appear. You need at least one active breakpoint (not sure if the problematic background breakpoint(s) count so set one). Thanks! Much faster now... – Reive

Indeed this works! Incredible! Has anyone already reported this obvious bug to Microsoft? – Lansquenet

This happened to me when I tried to manually add a breakpoint using CTRL + B and then typing in the function name and ignored the warning that IntilliSense wasn't able to find the function. – Chaddie

I am having the same problem in VS2015 but I can't find 'Delete all breakpoints' option, any idea where did they move it if it exist there afterall? – Mord

Ctrl+Q (or click in the "Quick Launch" box in the top right corner) and type "delete" (or "breakpoints" or "delete all breakpoints" :) ) – Vacillating

Wow - after looking at all these obscure, complex suggestions/solutions everywhere (often which have side effects), this is the simple and effective answer. Thank you! – Carmencita

The problem arises again after couple of hours. Is not there any permanent solution? – Gwenni

Ctl+Shift+F9 if you're like me. ;) – Irreversible

It looks like you have solved this issue for me in VS 2017 as well. Thumbs up (if it indeed appears to be the fix, I've already tried so much) – Kiln

Answer 2

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.

Quaker

The "Just My Code" option is not available in the Options dialog in some Express versions of Visual Studio (it is in Visual C# 2010 Express, though), but it can be changed by other means: How do I disable 'Just My Code' in Visual Basic 2005 Express?. – Anagnos

This is the one that fixed it for me...not the "Delete All Breakpoints" answer. – Timofei

This is just about the worst option in Visual Studio. Far better to just disable the symbol loading so you can still see exception throws and stack frames that are simply missing symbols. (Just some difficult to read number instead of a name). Of course, I usually work on website code, so there's a whole lot of IIS underneath me that can fail. Normally just deselecting Microsoft (and all remote) symbol servers as a source for data will work. – Raney

Answer 3

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

Jacksnipe

Answer 4

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.

Pehlevi

In the Tools -> Options -> Debugging -> Symbols dialog there is no Symbol file (.pdb) location added. And I pointed in my project's debug directory at the field below, and I checked the "Search the above directory only when symbols are ...." checkbox. I don't know how should I set up this dialog to turn off symbol loading. – Tarkany

Hmm, I don't know then. You need to load symbols for your own code to debug it so I don't think you want to turn it off entirely. I guess then I'd look at the Modules window to see which had symbols loaded, work out which ones you actually need and then maybe delete the .pdbs from your symbol cache for the ones you don't want? – Pehlevi

Check the 'use microsoft symbol server', run your code once, and then all the symbols are in Cache. You can now go uncheck the box for a speed boost. – Dyslogistic

Disabling the Microsoft Symbol Server in Tools -> Options -> Debugging -> Symbols fixed this for me. Before I was waiting 30 seconds for debugging to start. Now it's just a second or so. – Stakhanovism

Answer 5

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

1. Go to Tools -> Options -> Debugging -> General

2. CHECK the checkmark next to "Enable Just My Code".

3. Go to Tools -> Options -> Debugging -> Symbols

4. 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.

5. 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.

6. UNCHECK the checkmark next to "Microsoft Symbol Servers" to prevent Visual Studio from remotely querying the Microsoft servers.

7. 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

Drucie

For me it was only necessary to check "Enable Just My Code" – Mucin

Answer 6

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.

Buber

This solved the problem for me too (I guess the low number of upvotes is due to the low number of people that have set this variable...) Thanks! – Crespi

Same here. I thought I could just uncheck it from symbols, but no, the env var has to be removed / renamed. – Mckelvey

Answer 7

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.

Septimal

thank you for this crazy workaround (with the 'do you want to stop debugging' message). i tried the other answers first, but so far only the red "X" and the 'do you want...' trick is helping. thank you, i was losing my sanity... – Dorcasdorcea

@que: Heh, you're welcome! I discovered it by accident. It seems like VS has a separate message loop that it goes into for that modal dialog, so whenever it's being sluggish for no reason popping the dialog sometimes helps :-) – Septimal

Answer 8

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...

Palawan

Answer 9

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

1. 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
2. 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.

Nuke

Answer 10

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://mcmap.net/q/48013/-slow-symbol-loading-in-an-asp-net-project-in-vs2012

Farrington

Answer 11

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).

Sky

Answer 12

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

Marriott

Answer 13

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'

Id

Answer 14

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.

Discourage

Answer 15

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.

Cauterant

Answer 16

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

Befuddle

Answer 17

In Visual Studio 2022, I was having issues with debugging being painfully slow.

Options -> Debugging -> General -> Uncheck Enable Diagnostic tools while debugging

I think the CPU and Memory profiler were doing some extra tracing and slowing it down.

Ludwog

Answer 18

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

It turns out I added some "Command line arguments" in the Debug options, and one of the parameters is invalid(I am supposed to pass in some values).

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

Levileviable