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.
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.
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.
Just try this Debug -> Delete All Breakpoints.
Its works on me.
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.
Related
I'm using Visual Studio 2017 and I'm developing WPF application that load dlls from other users by using:
Assembly.LoadFile(filePath);
After every load, the visual studio try to load the symbols from these dlls and sometimes it take a lot of time.
I have found several solutions that didn't work for me:
Enable "Just My Code" - didn't work
Specify excluded modules - didn't work because I use cache mechanism that gives every time the dlls different file name, so I can't specify the actual file name.
_NT_SYMBOL_PATH variable is not defined.
Is there a way to load the dlls without the symbols? Or prevent from visual studio to load symbols from specific folder (All the dlls are in specific folder)?
Update:
I tried also:
Delete All Breakpoints - didn't work
Uncheck all non-local sources for Symbol file (.pdb) locations e.g. Microsoft Symbol - didn't work
Load only specified modules - Could work but I prefer not to maintain this list because I use many projects and I open the solution from different locations. Maybe there is a way to load only .pdb files from the solution?
Windows 8, VS2013 IIS8,5
I'm trying to connect to a local WEB API by connecting to processes w3pv.exe (Managed (v4.0.30319), 19). The website front end and back end is both running fine on my local IIS. Right after publishing my x86 web API to the local IIS i try to connect to the process, where the break point states "The Breakpoints will not currently be hit. No symbols where loaded for this document". My colleague' can without any problems debug from his local computer.
So far I have.
Reinstalled VS2013.
Checked All Debug Properties
-Project -> build: Define DEBUG constant check / Define TRACE constant check.
Generate serialization assembly = Auto. Advanced build settings -> Debug info = full
Enable Just My Code: Check, Use Managed Compatibility Mode: Check
Enable Edit and Continue : Check
Made sure all Debug mode is set and all project Configured to Active solution platform x86, marked Debug and Build.
Deleted all bin and obj folders, as well as pdb folder in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
Reset IIS.
Set Select Code Type to Automatically determine the type of code to debug
Checked in IIS that .Net compilation -> Debug and Enable Prefetch is set to true.
And I still get the same error message. Anyone found anything in addition to this?
I have encountered similar problems many times while training new employees in our very complicated devenv, so here is our internal step by step instruction:
Don't panic
Make sure you attached the debugger to the correct process - you debug the plugin by launching VMS which is external app that has separate config file where the plugin path is stored, so when you change just your configuration Debug/Release it doesn't work.
Make sure you have symbols generated for the assembly Project properties->Build->Advanced->Output section
Make sure the build path hasn't changed. You may have accidentally changed the path and you may only think that the assembly you are trying to debug is the correct one.
Investigating the information you provided this is only help I can think of. My guess is the files you publish are not the files you're debugging locally.
RESOLVED (embarrassed)
A few day's ago, I downloaded the front-end code for the website from the VPN (GIT). I forgot to update the code-behind reference in the App.js file in the front end root. This, of course, referred to the API on the cloud, and not my local API.
This took me way to long to find out. But, at the same time, it's not a solution I've seen so far on the web.
Thanks for all your help.
My solution uses classes from .dlls generated by my other solutions
.dll where generated in debug mode on the same machine, pdb files are present
steeping into those external sources during debugging works, so I am assuming pdb files are correct
pdp files are in the same directory as .dlls
In R# settings I have "Navigation to Sources" selected and "Use debug information for navigation checked"
VS2012 Pro and R# 8.02 Full
It drives me crazy, how come such crucial thing, that is provided out-of-the-box in every common free IDE for Java, is impossible to get to work in C# using tools for hundreds of bucks...
Looking at the dump in the gist you posted, the first issue I can see is the empty section for PdbCacheManagerImpl. This is the list of pdbs that ReSharper knows about. This shouldn't be empty. There is a known bug that can cause this to be empty. Try closing and reopening the solution to see if that kicks it off again.
Similarly, the assemblies in your PdbServiceImpl section don't include any information about pdbs. I think this is related to the PdbCacheManagerImpl - since ReSharper doesn't know about the pdb files, it doesn't get listed here. When it's working, it should show the pdb file related to the assembly, plus a list of all symbols in the pdb, and the file(s) they map to.
(I can recreate this by creating a new solution - the dump shows nothing in this section. Close and reopen and it shows known dlls, with flags to say if they support source servers and whether they contain a map between symbols (types) and source files. After closing and reopening, I can download and see source for e.g. Console.WriteLine, and the PdbServiceImpl has an entry for System.Console in the mscorlib pdb)
Secondly, you don't have "Allow downloading from remote locations" enabled in your options. This will only affect you for downloading pdb files from symbol servers, it shouldn't stop things working with pdbs next to dlls. You will need it enabled to navigate to source of Console.WriteLine, though.
So, unfortunately, my advice right now is to close and reopen the solution, and try again. You might be hitting the known bug, and the only way to work around this is to close and reopen. Once you've reopened, try navigating again, and try dumping the support information again - you should see more pdbs in the PdbCacheManagerImpl and a list of known symbols in the PdbServiceImpl section.
I am trying to configure visual studio to enable me to step into the .net framework source code when I am debugging.
I have tried with both Visual Web-Developer-Express-2010 and Visual-Studio-2011-Express-For-Web as well as Visual-Studio-2011-Express-For-Web on Win8CP and I am getting the same problem with each.
I have read numerous tutorials on how to set it up and the settings I have I believe to be correct.
Debugging General Settings -
also -
Debugging Symbol Settings -
I have tried both of these symbol servers. When I click Load all Symbols this is the output I get saying symbol loads have failed -
Large scale version link
If I run the code to the breakpoint, right click and select the specific method to step into like so -
large scale version link
I get this tab -
Large scale version link
If I look in my SymbolCache folder, there is only a FailedLoads folder with these contents -
Large scale version link
My project is in debug mode. I have also tried running VS as administrator. I have full control over the SymbolCache directory. I am on a home network and have full access to my internet connection.
Why is this not working?
Source stepping is only available for RTM or SP releases.
See http://social.msdn.microsoft.com/Forums/en-US/refsourceserver/thread/1b74f60c-e961-425c-a38e-362406dd4cfe.
Since 4.5 assemblies keep the same version number as 4.0 (stupid idea), then there is no way to get compatible symbols + source right now, so this is impossible with VS11 installed. You must start over with a clean machine and don't install .NET 4.5.
This is really stupid … the whole point of versioning just thrown out the window.
Have you set up the environment to load the symbols (note: by default, the symbols are not set to load - have not checked VS 11, btw (will do so later)).
You can also check out this article for info on symbols. I will have to check if there is a manual download for symbols for .NET.
You can also set up source server manually to http://referencesource.microsoft.com/symbols. You cannot browse the reference source.
I had this problem - no symbols loading - and spent a week trying to solve it. My problem was that I had for the first time started using Master pages in my website project. And I was incorrectly creating the content pages; the error was that i was not indicating the codebehind file in the page directive of the content page so my codebehind file was in essence unconnected to the build of the project. A dumb mistake and simple fix after a week of frustration. Hope this helps some lost programming soul stuck with the same problem.
When compiling a library or an application (e.g a Console Application in the Visual Studio IDE), in the Debug folder of the application, apart from the .dll or .exe, there will be one more file with extension ".pdb".
What is the exact usage of this .pdb file?
PDBs contain debugging symbols, so you can ship a compiled binary to your customer without exposing your source code algorithms and other private details to them.
If your app goes wrong on a customer site, you can get a crash dump from them (using DrWatson), bring it back to your dev workstation and debug the crash, the debugger will use the symbols file in conjunction with the crash to show you the source code, data structures etc. In many cases, all you have to do is open the crash dump and the debugger will take you directly to the source code of the exception, and show you variables and threads too.
That's the primary use of them, they're invaluable when a customer reports a crash. The things you need to know about using them though - they are only valid for the build that created them, so if you recompile, your symbols file is next to worthless.
John Robbins has an excellent article why you would use them.
John Robbins has written some really great articles on PDBs lately:
PDB Files: What Every Developer Must Know
Visual Studio Remote Debugging and PDB Files
How Many Secrets do .NET PDB Files Really Contain?
Do PDB Files Affect Performance?
Correctly Creating Native C++ Release Build PDBs
PDB's allow debugging of applications, for examlple when they crash or if you have a minidump. They also allow you to find more detail about errors when outputting exceptions to logging (they will give a more complete stacktrace with line numbers rather than just showing the name of the function where the error occurred).
PDB's are useful when you want to do remote debugging as well.
Keeping the PDB's together with your installed application makes it possible to hook up visual studio remotely to the client's production environment and debug the application when necessary.
Well you've given yourself a big clue in your title.
It's the file Visual Studio needs to be able to debug your application.
This MSDN page has more information.
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program.
As far as i know, they contain debugging information, such as line numbers, variable names, etc.