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.
Related
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.
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
I have developed an UWP app that uses a lot of NuGet packages (MvvmLight, SQLite, ...) and other resources (Syncfusion controls).
I encounter a bug with the Store app, which is already published for tests, that is not present when I build the app in "Debug" mode.
So, I've tried to debug in "Release" mode, with the checked options "Compile with .NET Native tool chain" and "Optimize code". The build ends successfully, but I encounter an exception with a Syncfusion control (SfDataGrid) on the main page of the app. I would like use breakpoints to understand what happens, but they are deactivated as I build the app in "Release" mode.
If I build the app in "Debug" mode, with the same options checked ("Compile with .NET Native tool chain" and "Optimize code"), I don't encounter the same bug with the Syncfusion control, and the defined breakpoints are well keeped.
So I don't see how I could fix my problem:
if I create a new solution and built it in "Release" mode, the breakpoints are well keeped, and I can debug the code
if I build Syncfusion samples in "Release" mode, it's the same thing: the breakpoints are well keeped, and I can debug the code
I have compared the "build" parameters of the app and the other ones: they are the same
I have also looked at the "Just-in-Time" page, in the Visual Studio "options". I've got the following error: "Another debugger has registered itself as the Just-In-Time debugger. To repair, enable Just-In-Time debugging or run Visual Studio repair.". Ive tried to "repair" Visual Studio, but it's always the same thing...
Here is the "Options" settings:
And the result in solution, where breakpoints are disabled:
Would you have any explanation? How could I do to debug my app in "Release" mode?
[Edit 1]: add some details after further investigations
My app is based on a "template" like Template10, called Nentang. The structure of the project is the same, and they share a big part of references or NuGets packages.
But if I compare the build result of the "blank" Nentang and my solution, there are some differences that I don't understand:
as explained, on my app, the breakpoints and debug don't work in "Release" mode, and I can see that almost all modules don't have any "Symbol File":
=> only "ntdll.dll" and "KernelBase.dll" are linked to thier pdb file in a local directory: "C:\Users\myname\AppData\Local\Temp\SymbolCache"
on the "blank" Nentang app, the breakpoints and debug work well in "Release" mode, and I can see that almost all modules have a "Symbol File":
=> allmost half of the modules are linked to the same file in the "project" directory: "C:\Projects\Samples...\Nentang.UWP\bin\x64\Release\AppX\Nentang.UWP.pdb"
=> another quarter of the modules are linked to the same file of a "system" directory: "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.NET.Native.Framework.1.3\1.3\x64\ret\Native\SharedLibrary.pdb"
=> the other modules are not linked to a Symbol File: it's the case of "ntdll.dll" and "KernelBase.dll"
How could I restore the "Symbol files" of my project?
I have also remarked a "strange" parameter in the properties of my solution, that is not present is the Nentang properties:
There is this parameter: "f:\dd\ndp\fxcore\CoreRT\src\System.Private.CoreLib\src\System\Runtime\ExceptionServices\ExceptionDispatchInfo.cs"
What does it mean? Could it explain my problem?
Debugging optimized code is always a challenge - even more so with .NETNative. Here are a few things you could try:
Disable Just My Code
Suppress JIT Optimizations: This will not help for modules built with .NETNative toolchain. If the exception occurs in Release builds without .NETNative, then check the debugger option called "Suppress JIT optimization on module load (Managed Only)". As the name implies, this will cause the CLR to JIT compile code unoptimized, which will allow you to set breakpoints and inspect locals.
Look at the Output window for clues as to what went wrong. The exception message will be there and the preceding messages may help diagnose the cause.
Debug your application with Native debug engine. You can do this by checking the Native checkbox under the Debug tab of the project properties.
Last resort is to debug the assembly.
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.
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