Visual Studio loading symbols

后端 未结 16 1854
清酒与你
清酒与你 2020-12-02 04:37

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

相关标签:
16条回答
  • 2020-12-02 05:10

    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

    0 讨论(0)
  • 2020-12-02 05:12

    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.

    0 讨论(0)
  • 2020-12-02 05:12

    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

    0 讨论(0)
  • 2020-12-02 05:12

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

    0 讨论(0)
  • 2020-12-02 05:13

    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

    0 讨论(0)
  • 2020-12-02 05:17

    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.

    0 讨论(0)
提交回复
热议问题