When debugging the below following message appears in the immediate window. Can anyone explains to me easily what exactly does it mean and whether I should enable something related to this? Notice that I have already found some information on the internet but to be honest don't get it at all.
Use a debug build configuration or disable the debug option 'Enable Just My Code'.
Check the 'Symbols' settings under debugging options.Symbols for the module 'myapp.exe' were not loaded.
Use a debug build configuration or disable the debug option 'Enable Just My Code'.
Check the 'Symbols' settings under debugging options.
Sometimes, while you are debugging, you might want to look at only the code you have written and ignore other code, such as system calls. You can do this with Just My Code debugging. Just My Code hides non-user code so that it does not appear in the debugger windows. When you step, the debugger steps through any non-user code but does not stop in it.
Click here to read more about that topic in the documentation.
Related
I am debugging an app that makes use of System.Reactive.dll. I am not sure how it happened but all of a sudden while debugging VS will stop and show a "Source not found" window for basically anything from System.Reactive.dll. For example:
Subject.cs not found
You need to find Subject.cs to view the source code for the current call stack frame.
This happens for Merge, RefCount, TakeUntil, Select, etc.
"Enable Just My Code" is checked in the debug options. I am not trying to step into any of these reactive methods (I am just hitting F10 while debugging).
How can I disable this? It is making debugging the app impossible.
According to your description, If “Enable Just My Code” doesn’t work you can try the following methods:
check Enable source server support under Tools > Options > Debugging > General
Reset all settings under Tools > Import and Export Settings
I use VS2017 and I get the following when I hit F5
It happens for certain projects only, even if I disabled the Symbols support under VS options. Although in the past, for the same projects it used not to throw even with Symbol support enabled.
So, since I assumed this must be some kind of cached VS setting project specific, I deleted bin, obj, .vs , SymbolSource folders but the same.
If I enable Just My Code it does not throw, however this is not what I want since I cannot debug assemblies which I already have the symbols.
As far as I know even if Symbols Support is enabled it shouldn't throw if there isn't a related Symbol Server declared in VS Options.
This behavior is not specific only to System.dll but happens even if I attach to external processes which I do not have symbols, meaning that filtering with the Load Only Specified Module VS option again is not what I am looking for.
So, does anybody have an idea on how to avoid such annoying exceptions while allowing to utilize Symbol Support for other assemblies which I have configured.
It means that you want to step in to the
.net Framework source code:
http://referencesource.microsoft.com/setup.html
http://referencesource.microsoft.com/indexedpdbs.txt
Actually we also reported this issue to product team for VS 2017 before:
Stepping into .NET Source Still Doesn't Work
If you really want to avoid it, I suggest you disable settings like "Enable .NET framework source stepping" under TOOLS->Options->Debugging.
To debug .NET framework source code,we need to:
Disable just my code
Disable step over properties and operators
Disable require source files to exactly match the original version
Enable .NET framework source stepping
Enable source server support
So just use the contrary settings as above options, debug it again.
In addition, please enable the symbols server under TOOLS->Options->Debugging->Symbols Server, and enable the exception settings window, view the detailed exception messages, maybe you have to resolve the Exception firstly or get any helpful information from it.
Try to uncheck the debug hosting service.
None of the above worked for me because I was using external DLL which didn't have the PDB file with it. I found that when I removed all the breakpoints.
Go to Debug menu > Windows > Exception Settings (or press ctrl + alt + E)
Now check Common Language Runtime Exceptions or click Restore default (Refer screenshot):
So when it throws exception and you don't see it, it want to use the PDB file to store the stack trace but it didn't find it.
I had to check Enable native code debugging under Debug tab in project properties to get rid of this issue (Refer screenshot)
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.
I have a problem in Outlook 2010 add-in project, After first debugging for the project I can't debug it one more, it show me the following warning :
The following module was built with optimizations enabled or without debug information:
{Path to DLL}
To debug this module, change its project build configuration to Debug mode. To suppress this message, disable the 'Warn if no user code on launch' debugger option.
and it didn't take any change I have made.
To debug, you need debug symbols and non-optimized code - make sure you have Debug symbols enabled for your build configuration, i.e. Define DEBUG constant checked and optimizations disabled, i.e. Optimize code unchecked.
not sure what else to try, but i am not able to step through the .net source code.
In the debugging options
Enable just my code is unchecked.
enable source server support is checked.
Enable source server support is checked.
In the debugging symbols
1. Microsoft symbol servers is checked.
2. cache symbol directory is set.
when i try to step through some system.servicemodel.dll stack trace,
in the modules windows, i can right click and load symbols for servicemodel dll
it flashes the cancel dialog, like its doing something
the stack becomes black from grayed out
but when i click on the method it shows no source code available
any other ideas ?
I suspect Visual Studio could not find the appropriate code for your DLL. Perhaps the easiest way is to re-build the DLL, and reference the DLL with the code in the expected directory. Let's try that first, and see what we can learn from your testing.