I'm attempting to debug into a method in a library (which was installed via NuGet, if that matters), and Visual Studio is skipping over it with the message:
Step into: Stepping over method without symbols
'Cpi.Net.SecureMail.CryptoHelper.FindCertificate'
I have a symbol server source added in the debug settings, and when I first debugged the program, it told me it was downloading the symbols for this library. I have verified that the symbols were indeed downloaded, as they show up in my symbol cache directory.
Thanks to SLaks, I know now that the PDB that has been downloaded from the symbol server is apparently in an obsolete format. If I retrieve the PDB directly from TeamCity's build artifacts, the debugging works.
So, it appears, that somehow, or for some reason, the PDB file is being altered either through the NuGet packaging process, or through the Symbol Server download process (ProGet).
The scope of the question has now, apparently, widened significantly.
It turns out that ProGet is indeed mangling the PDB file, in order to have it point to the source server instead of the local build folder for the source files. For some reason, ProGet is creating a PDB that Visual Studio doesn't like. Inedo and I haven't been able yet to nail down why.
Related
[Environment: W10 x64 Pro v. 20H2, Visual Studio Pro 2019 16.9.4]
I am attempting to debug an open source project, which is a Visual Studio Extension (AnkhSVN2019) and am able to start a VS Extension Debug session where my modified code is being executed.
However, any breakpoints I set in the code are disabled at runtime, and when I mouse over the disabled breakpoint, I get the message
The breakpoint will not currently be hit. No symbols have been loaded for this document.
When I am in the debug session, and I open the Modules window (Debug -> Windows -> Modules), I see that my dll I am interested in is loaded and located at c:\users\conrad\appdata\local\microsoft\visualstudio\16.0_b1ddb83bexp\extensions\extensions-16.0_b1ddb83b\wyo52n3q.czx\Ankh.UI.dll. (It is indeed there.) There is no Ankh.UI.pdb in that directory though. Some hopefully relevant observations:
The file Ankh.UI.pdb does exist in the ...\bin\Debug\ dir of the project
The timestamp for the above Ankh.UI.dll is older than recent edits I have made to files within that .dll
Looking around, I see there is an updated Ankh.UI.dll in C:\Users\conrad\AppData\Local\Microsoft\VisualStudio\16.0_b1ddb83bExp\Extensions\Phil Jollans\AnkhSVN2019\1.0.12\ but no .pdb files in that dir either (Phil Jollans is the owner of AnkhSVN2019 on github)
Back in the Modules window, if I right-click on the Ankh.UI.dll line and choose Symbol Load Information…, a dialog opens with the following information:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Ankh.UI.pdb: Cannot find or open the PDB file.
c:\users\conrad\appdata\local\microsoft\visualstudio\16.0_b1ddb83bexp\extensions\extensions-16.0_b1ddb83b\wyo52n3q.czx\Ankh.UI.pdb: Cannot find or open the PDB file.
C:\AnkhSVN2019\src\Ankh.UI\obj\x86\Release\Ankh.UI.pdb: Cannot find or open the PDB file.
C:\Windows\Ankh.UI.pdb: Cannot find or open the PDB file.
C:\Windows\symbols\dll\Ankh.UI.pdb: Cannot find or open the PDB file.
C:\Windows\dll\Ankh.UI.pdb: Cannot find or open the PDB file.
(btw there is no C:\AnkhSVN2019\ directory.)
What am I missing here?
I have download this project, but how do you debug this project?
I use below steps to debug it, the breakpoint(Ankh.UI) can be hit, and Ankh.UI pdb file can be loaded.
Right-click the Ankh.Package project
Open Debug page
Change Start Action to Start external program with "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe"
Add /rootsuffix Exp in Command line arguments
Got this list of sufficient (although maybe not completely necessary) steps from the Extension owner to get my environment in a state where the Extension is debuggable:
start the experimental instance (in the debugger)
remove AnkhSVN from the experimental instance (via Extensions/Manage Extensions)
close the experimental instance
remove AnkhSVN from the normal instance
close visual studio
in the start menu, click the Reset Visual Studio 2019 Experimental Instance link
open AnkhSVN in visual studio again
clean the solution
start the debugger (which will rebuild the solution – do not build the solution first!)
if it doesn't install AnkhSVN into the experimental instance, then close it and start the debugger again
This list of steps is IMO completely crazy and shouldn't be necessary to debug an Extension. Can't tell if this is a VS shortcoming or due to the Extension being poorly architected. But at least now I can debug it.
How can one debug the .NET framework source code using Visual Studio 2017?
There are some questions here on stackoverflow about this topic, but even after reading all of them, I still wasn't able to make it work.
I thought it would be useful to present an up-to-date, working solution about how to debug .NET framework source code.
I would like to solve it without using any external tools (e.g. dotPeek as source server).
First of all, I tested it using Microsoft Visual Studio Enterprise 2017, Version 15.9.7 and via .NET Framework 4.7.2. Though, I think it should work on Community edition the same way.
Steps to take:
Go to Tools / Options / Debugging / General, and perform these settings:
check Enable .NET Framework source stepping (this will automatically disable "Enable Just My Code"; if not, do it manually)
uncheck Require source files to exactly match the original version
check Enable source server support
Go to Tools / Options / Debugging / Symbols, and:
in the upper listbox check Microsoft Symbol Servers
click Empty Symbol Cache button (to make sure you will get the correct symbols)
select Load all modules, unless excluded radio button at the bottom
Download the source of the .NET framework version your project is targeting, from the https://referencesource.microsoft.com/download.html site.
Unpack the downloaded archive (zip) file to a convenient path on your PC.
Debug your application; set a breakpoint to the line of .NET code you wish to debug, and step to the desired code line with the debugger.
Note: your application may start slower since it will download PDBs from the internet.
Press Step Into (F11 by default). If your settings are correct, this will cause some delay (if your VS crashes (like mine did), Empty Symbol Cache again). Eventually it will ask for the sources of the given file, e.g. dictionary.cs.
Two things can happen here:
A) It asks for the source file (.cs) in a file dialog. Go to step 7.
B) It says whatever.cs not found, and there is a link that says "Browse and find whatever.cs...". Click that link.
Select the corresponding .cs file on your disk (you can search for the file on the OS).
Note: I had to restart VS several times until it "did not crash" while looking for sources, this is most likely a bug in VS.
If you did everything correctly, you will find yourself debugging the .NET source code.
Note: Since VS saves the path you entered for the source files, you can stop debugging or restart VS; it will work next time, too.
Besides, you do not have to manually select any more source files within the framework, because the VS will use the source folder you entered and will search in source files there.
Many people wondering why they can't step into source although they does set the checkboxes as described above. I'm, too.
Because you can extract dotnet sources to any location, Visual Studio isn't able to know about them and the reason can't be the source files itself (why Visual Studio doesn't find the files).
But some dll's are browseable, some not (through double clicking in Visual Studios stack view or context menu > goto source). This brought me to the assumption, that the .pdb itself must be the reason. If you look into a file which works (e.g. notepad), you see at beginning a list of strings with file pathes (source files). In files, which doesn't work, the files starting immediatelly with binary data.
For some reason microsoft doesn't create her .pdb's with full debug information in every build process. But why not - good question! g
In short: you have to search a dll version of your file (which you like to debug) which contains FULL DEBUG INFORMATION. This is also the reason why context menu disables "goto source".
I'm replacing this file temporary in global assembly cache for time of debug. This works for me.
Here an example of PresentationFramework.dll
- 4.0.30319.298 => pdb size: 1219 KB
- 4.0.30319.18408 => pdb size: 15.562 KB
Perhabs somebody can create a public database (wiki), which everyone can add files and versions for which full debug information are available?
(If you are like me and after following all steps you still can't step into code...your PDBs downloaded from Microsoft are wrong, try this)
Using JetBrains dotPeek as the symbol server worked for me. (4.6.2 framework) (I did everything mentioned in this thread and many more threads, and nothing worked)
https://hmemcpy.com/2014/07/how-to-debug-anything-with-visual-studio-and-jetbrains-dotpeek-v1-2/
JetBrains dotPeek decompiles your actual .NET DLLs, then hosts a symbol server that you download symbols from in Visual Studio. After a pretty slow download, then a restart of VS, I was able to breakpoint and step into the code.
You can find the path to your .NET DLLs in the "Modules" window when debugging in VS. Enter this into dotPeek. Then Host Symbol server in dotPeek. Then add http://localhost:33417 as your symbol server in VS symbol settings. then load those symbols. it takes a minute and a VS restart, but works.
I am trying to open a dump file using Visual Studio 2012 but there are some PDB files missing.
Is there a way to make the debugger use another PDB file, built on my machine?
Unfortunately, I can't access the original DLLs and PDBs.
I'm trying to open my PDBs using the "Browse and find ***.dll..." button but I'm getting an error message saying "a matching symbol file was not found in this folder"
Visual Studio does not have an option to ignore mismatched symbols. Other debuggers (like WinDbg) have that.
ChkMatch is able to modify a PDB file so that Visual Studio does not recognize the difference any more. However, the result is what it is: even a slight modification might cause the compiler to emit totally different code. What you see in Visual Studio may be totally misleading. See this answer for details.
Be warned: delete the modified file immediately after your investigation or you will hunt ghost bugs sooner or later.
In the process of debugging my WPF project, I regularly encounter thrown exceptions. When these exceptions fire, if the exception is thrown by my application's code, I am able to browse the source code. All is well.
HOWEVER, if an exception is thrown by code hosted in another assembly (that we built), I am unable to browse for the source code. I was at some point in the past prompted to browse for the original source code file, but "canceled" the dialog. Now, I want a do-over.
Is there a way to grant me a do-over on locating these source files? I'm no longer prompted for them. I assume Visual Studio stores my source code browsing preferences somewhere, but I don't know where. I get the idea this do-over is possible, but I don't even know the words to search for on Google to get what I want.
What should I do?
In the Solution Explorer right click on the solution and go to Properties → Common Properties → Debug Source Files.
Then on the right hand side there is a list for "Do not look for these source files:". Deleting the entry from that list should prompt you for the source location again.
Delete the hidden .suo file in your solution directory.
You may have to reset the visual settings. You can do this by clicking "Tools", Import Export settings.
For the default source path, make sure your PDB files are replaced correctly where Visual Studio is adding your reference DLL from. The PDB file contains the path of the source code, it's not Visual Studio.
You must rebuild your project (referenced assemblies one) and manually delete PDB files in your debugging project before adding references. It may be a bug in Visual Studio in case the files are locked or if for some reason the PDB files may not be updated.
Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the running version and therefore there's a mismatch that causes the breakpoint to be disconnected.
Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.
Added Note:
This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.
Maybe this suggestion might help:
While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
Look for your project's DLL, and check the Symbol Status for it.
If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
I've found that it's sometimes necessary to:
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.
http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/
In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.
Is the build configuration set to Release?
Do you have a reference to an external DLL where the breakpoint is set?
Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?
If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.
Again, the above only applies to .NET + COM Interop DLLs.
I've had a similar problem in the past.
It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.
Read the post here and the comments to resolve it.
AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.
Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.
Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).
Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.
In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.
This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]
Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?
Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?