Why won't Visual Studio step into 3rd party code? - c#

I've reviewed the threads I can find on this subject, but none of the proposed solutions seem to help. So I'll ask again!
My Visual Studio 2015 will not step into 3rd party code for which I have the pdb in my bin folder when I run in debug mode. I even see the pdb file downloaded as Visual Studio loads symbols. When I attempt to step into the 3rd party code, Visual Studio complains that it can't find the .cs file. I've tried toggling the 'Enable Just My Code' setting. Visual Studio used to be able to step into 3rd party code; I'm not sure what changed.
I am attempting to step in the context of a unit test, in case that matters. The pdb file is in my unit test bin directory.
My debug settings are below. What am I missing?
Edit: Context menu from right-click on method in call stack

Make sure you have source code to source debug.
Pdb file only contains debug information which is like mapping between executable code and your source code. With pdb VS debugger knows where in source files each instruction is located, but it still needs to have source files to show you the code.
When it cannot find source file VS debugger will show dialog box to browse for the source file. So without source code, VS cannot debug it properly.
Workaround is to use some tools like Resharper, Reflector which could decompile it

Related

dll and pdb are loaded, but "no symbols have been loaded for this document

I've looked through the answers to about 5 similar questions, and particularly the top page of answers to this 1.5k upvoted question, but none of the fixes in there do anything for me.
I've inherited a C# project and am trying to debug it. I'm a bit new at C#, but have more than a decade experience with Visual C++. So I know my way around the debugger a bit at least, and have had to deal with debugging DLL's before. However, this one has me stumped.
I can set breakpoints in the main project's .cs files and they work just fine, but when I try to set one in a sub-project dll ("assembly"?) all the breakpoints show up at runtime with "The breakpoint will not currently be hit. No symbols have been loaded for this document."
What I've tried:
Clean and rebuild.
Clean, delete all copies of the dll and pdb from my hard drive, rebuild.
Verified the project props are set to Define DEBUG constant, Define TRACE constant.
Set the subproject (assembly) as the startup project, with the main exe (in the same directory as the DLL and PDB) as the Start external program
In the project build settings, Debug Info is set to full, and Optimize code is not set.
The debug option Enable Just My Code is not checked (I checked it, there's no checkmark in the box).
I'm not trying to build or debug in a Release configuration.
I've also checked the loaded DLL in process explorer and the Symbol Load Information in the debugger, and they match:
Process Explorer:
VS 2012's Symbol Load Information:
So its clearly got some PDB loaded, its in the same directory as the DLL, and they both get built when I build the project. The timestamp on the two files is identical. Yet VS'debugger doesn't think symbols are loaded for that file.

How can I get Visual Studio to use Embedded Source code whilst debugging?

I have embedded the C# source code into a portable PDB file using the <EmbedAllSources> element in the csproj file, and I have embedded the pdb into the assembly using the <DebugType>embedded<DebugType> as described in Embedding C# sources in PDB with new csproj
My assembly looks like this:
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<EmbedAllSources>true</EmbedAllSources>
<DebugSymbols>true</DebugSymbols>
<DebugType>embedded</DebugType>
</PropertyGroup>
I can confirm that the pdb is type portable, and contains my source code:
According to the release notes for Visual Studio 15.5 the debugger should be able to use these files during debugging:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.5#EmbeddedSource
I'm using Visual Studio 2017 (version number 15.8.8)
However, when I F11 into the code from my assembly it asks for the sourcecode:
Whilst googling around there's a comment from ctaggart in the discussion https://github.com/ctaggart/SourceLink/issues/192 which says running sourcelink print-urls will print "embed" but mine doesn't, perhaps this is a hint:
Has anyone got this to work successfully? If so can you tell what I'm doing wrong?
Easiest way is to go to:
Debug -> Windows -> Modules
Inside this list, you should be able to find your assembly (dll/exe).
Right click it -> Load Symbols
It will ask for where to load the symbols from.
Navigate to the directory where your matching .pdb file is.
It should auto load. Stepping into, or having uncaught errors in this referenced assembly should trigger a break in that code, or ask you to navigate to the code file that corresponds to the file that threw the error.
In our process, we generally have to navigate to the nuget cache to find the pdbs for our installed nuget packages. (%UserProfile%/nuget/packages/YourPackage/VersionNumber/../..)
We also package up the source with those packages and navigate to those /nuget/packages .cs files as well, though, any corresponding .cs file should allow it to load.

Cannot find debugging information when debugging c++ dll

there:
The Application is build from C#, and the Dll is built from C++, and they are in different solution. When I Launch the Dll's debugger, there is always a message box pop up, which says "Debugging information for 'App.exe' cannot be found or does not match.Skipped loading symbols for NGen binary."
Thanks.
p.s. I've try putting the App.pdb in several location, but still don't work.
As commented by ortang, you need to activate the debug info when building your project.
See "/DEBUG (Generate Debug Info) (Visual Studio 2013)":
The /DEBUG option creates debugging information for the .exe file or DLL.
The linker puts the debugging information into a program database (PDB). It updates the PDB during subsequent builds of the program.
It is not possible to create an .exe or .dll that contains debug information.
Debug information is always placed in a .pdb file.
To set this linker option in the Visual Studio development environment
Open the project's Property Pages dialog box. For details, see Setting Visual C++ Project Properties.
Click the Linker folder.
Click the Debugging property page.
Modify the Generate Debug Info property.

C# compiler including local path in EXE

When I compile a Release project (DEBUG is not enabled) in VS 2010, I'm seeing things like this in the generated EXE:
C:\Code\Test\Test\obj\x86\Release\Test.pdb
Why is this, and how can I disable it? I've tried Googling, but can't find much.
Allthough i havent actually tried looking in the exe file, you can disable generation of pdb files (and presumably their inclusion in the exe) from the project properties under Build > Advanced > Debug info. if you set this value to 'None', nothing should be generated
Even for release the default is to generate pdb files only.
These files are for debugging. They contain (among other thins) information on matching breakpoint in code to place in the compiled code. They should not be shipped with the binaries.

"Browse To Find Source" in Visual Studio 2010

When is "Browse To Find source" enabled in Visual Studio 2010? (see below)
In addition, I want to have it enabled so that I could browse to already-downloaded source code
files from http://referencesource.microsoft.com/.
This would be useful since Microsoft doesn't always release PDB/source code at the same time with their latest patches. So if I want to step for example into DateTime, I really don't care about the latest patches which didn't involve DateTime. I just want to browse to its code which I downloaded from http://referencesource.microsoft.com/.
After some investigations I found dia2dump which is a useful tool to view PDB file contents. (It's in C:\Program Files (x86)\Microsoft Visual Studio 10.0\DIA SDK\Samples\DIA2Dump\)
It looks like when I can't see source code for something like DateTime, using .NET Framework stepping, a mscorlib.pdb file actually gets downloaded.
But if you look inside it with dia2dump it doesn't contain source file mappings. In other words useless, because even if you could browse to the source code like my initial idea, it wouldn't work because there are no source file mappings and no start addresses of the functions, and a lot of stuff missing :(
I think the solutions here are to use .NET Reflector Pro for or keep a virtual machine at hand, with releases of the framework which have source code and then disable updates.
Introduction
Whenever you do a build from Visual Studio, normally, you also get a PDB file besides your executable file. You can see this file in the ..bin\Debug or ..bin\Release directory.
This PDB file keeps a mapping to your source code lines and executable code in your assembly. Also, the original locations of the source code files from which a build was done is stored inside a PDB file.
This means that if you build a class library which had a single file located at G:\ClassLibrary\Class1.cs, this path will be stored inside ClassLibrary.pdb.
What is important to remember from all this is that without a PDB file it is impossible to do source code step-in debugging.
Real-life scenario
So, suppose I do a build on my drive G:\ClassLibrary1, for a class library.
I give you a ClassLibrary.dll and a ClassLibrary.pdb file, or you get them by checking them out from source control.
You reference the ClassLibrary.dll in your project and you use a class from the library.
If you now try to step into class code from the library the following will happen:
Visual Studio tries to locate a ClassLibrary.pdb file in a couple of locations
1.1 If it doesn't find it, you get a "Browse to find source" disabled
page. Remember, you can't debug without a valid PDB file.
1.2 If it does find a PDB file, it looks inside the PDB file and sees that you are trying to debug Class1.cs which was originally built from
G:\ClassLibrary1\Class1.cs
and looks on your computer for that file.
1.2.1 If it finds it, it steps into the code automatically.
1.2.2 If it doesn't find it, you get the following dialog:
If you press Cancel, you will be presented with the: "No source available" and you will have "Browse to find source" enabled in this case.
Why? Because you have a valid PDB file, but Visual Studio can't possibly know where you have the source code for ClassLibrary1 on your computer or if you even have it on your computer. That's why you got the dialog -> so that you can point Visual Studio to the exact location of the source code file.
Final notes
So what will you do when you get a browse to find source disabled?
In Visual Studio, you open menu Debug -> Windows -> Call stack.
You right click on the top call stak instruction and you choose "Symbol Load Information". It will show you the locations where Visual Studio has tried to find a valid PDB file.
1.a If you only see "Cannot find or open PDB file" messages put a valid PDB file at any of these locations. (You might have to scroll right to see the messages) Stop and start debugging again.
1.b If you see a "PDB does not match the image" message it means the following. Visual Studio has found a PDB file, but it is for another build. If I build ClassLibrary1.dll and give it to you, and then I build it again without changing a single line of code and then give you the PDB, and you try
to debug classLibrary1.dll you will get this message. The assembly and its PDB file must be exactly from the same build, otherwise you will get this message. (This check is done using some unique number put inside the assembly and PDB file every time you do a built)
1.c You see a "symbols loaded" message but still get a "Browse to find" disabled. It means that the PDB file you have is not good for step-in debugging. Some PDB files you try to use don't have all the information in them necessary for step-in debugging. I think you can control this from somewhere in the advanced build settings, but I haven't tried it though, because I want to have usable PDB files generated everytime I do a build. This situation often happens if you try to debug the source code of the .NET framework itself and Microsoft hasn't put usable PDB files for the source code, but instead Microsoft has put some PDB files which can't be used for step-in debug. This happens more often than you think, because often Microsoft makes updates (patches) to the .NET Framework source code. These updates silently install onto your computer via Windows Update, and you are surprised to see that yesterday you could debug .NET Framework source code and today you can't. It usually takes some time until they put a valid PDB file for the latest code. In this case you can use .NET Reflector Pro step-debug ability or a virtual machine which has a .NET framework version with usable PDB files and disable Windows Update on that machine.
Check out the article Step Into .NET Framework 4.0 Source Code.
If you encounter the “No Source Available” screen, try to press “Browse to Find Source” and find the file you need in the source directory. You should probably need to use files search to find it.
This is done only once, since from now on Visual Studio remembers this location and searches there for missing source files.
I hope it's about what you are looking for.
Similar issue in Visual Studio 2019 can be resolved by checking "Enable Just My Code".
Debug > Options... > Debugging > General > Enable Just My Code
More detail explanation can be found here How to fix debugger is looking for executioncontext.cs

Categories

Resources