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.
Related
When I'm unit testing in VS2017, if I mistakenly press F11 while on method calling something that I DONT want to step in, it will step inside and I get this painful and irritating message.
WinTypes.pdb contains the debug information required to find the source for the module WinTypes.dll
This happens when I have call to windows runtime libraries or framework libraries. I DONT want to step inside these libraries. and no matter how many times I press F10 again or close this page, this message wont let me continue .
All I have to do is to reset debug process and start from over again... I was bearing with this for a while but ive had enough. this is driving me CRAZY. please show me way how to stop this stupid error.
.Net framework source stepping is also unchecked, but I'm unit testing UWP project.
PS: Just my code is also enabled FFS -.-
Please make sure the WinTypes.pdb has been loaded first. You could add a breakpoint in your code where before this issue occurs. And then open Debug -> Windows -> Modules. It will list the statues of all dlls that in your project. If the pdb file for WinTypes.dll is skipped, which is similar with below screenshot, you could right-click on it to choose "Load Symbols".
If load failed after choose "Load Symbols", please check the Symbol Source from Tools menu -> Options -> Debugging -> Symbols to make sure the Microsoft Symbol Servers has been checked.
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)
Here's what I've tried:
Made a new Console App (.NET Framework) in Visual Studio 2017.
Added the following code:
static void Main(string[] args)
{
new Dictionary<int, int>().TryGetValue(3, out int x); //I want to step into TryGetValue() (this is just an example)
}
Configured the settings listed here:
https://blogs.msdn.microsoft.com/sburke/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code/
Confirmed symbols are loaded in the Modules window:
mscorlib.dll Symbols loaded. 4.6.1586.0 built by: NETFXREL2
Tried: "Step Into (F11)"
Tried: "Step into Specific" | "System.Collections.Generic.Dictionary.TryGetValue"
Both just step over the line.
I've tried configuring VS using the details here: http://www.symbolsource.org/Public/Home/VisualStudio
Same result, the debugger steps over the line.
I've looked at the answer here: https://stackoverflow.com/a/12432029/297451
But this version doesn't seem to be a security update, and a search for "site:support.microsoft.com/kb 4.6.1586.0" yields nothing.
What am I doing wrong?
Here is the answer, thanks to Hans Passant. Note that this solution raises additional questions.
Ensure https://referencesource.microsoft.com/ contains the exact version you're debugging.
How? Reference source specifies ".NET Framework 4.6.2" but a module version is something like: "4.6.1586.0"
You may need to uninstall security updates as explained here: How do you enable "Enable .NET Framework source stepping"?
Configure Visual Studio as specified here:
https://referencesource.microsoft.com/setup.html
Untick "Enable Just My Code"
Tick "Enable .NET Framework source stepping" (this should have been the only step needed)
Tick "Enable source server support"
Untick "Require source files to exactly match the original version"
Confirm symbols are loaded in the Modules window, with source indexing included.
How can you tell if source indexing is included? The modules window doesn't specify if a PDB has stripped source information.
Microsoft could make this process a lot more robust by giving helpful error messages instead of silently failing.
Use the Symbol Server feature in JetBrains dotPeek. Worked like a charm for me after struggling to get the standard functionality to work:
Run dotPeek and go to Tools > Options... > Symbol Server.
Ensure that "All assemblies" is selected and copy the local symbol server URL to the clipboard. Start the dotPeek symbol server by clicking it in the Tools menu.
In Visual Studio, go to Tools > Options... > Debugging > Symbols and add the dotPeek server URL to the list. Move the dotPeek symbol server as high up the list as possible, and uncheck all other symbol servers in the list (in particular, the "Microsoft Symbol Servers" and "NuGet.org Symbol Server" must not be selected).
Start debugging - when you attempt to step into Framework source code, you will see dotPeek doing some work decompiling the assembly for you, and then you will be into its source.
If this doesn't work, it's probably because Visual Studio has previously downloaded the "wrong" symbols for the assembly in question from Microsoft/NuGet, and is using them instead of asking dotPeek. To check this, start debugging and find the relevant assembly in the modules list (Debug > Windows > Modules) - delete the PDB file at the path displayed under "Symbol File" for that assembly, then restart debugging, and dotPeek should kick into action.
I have a C# Service that is calling a C DLL that was originally written in VC6.
There is a bug in the DLL which I am trying to inspect.
After having a nightmare trying to get debug to work I eventually added the dll to the VS2005 solution containing the C# Service and added the necessary _CRT_SECURE_NO_WARNINGS.
The debug version of the service is registered using 'installutil.exe' tool.
I can get the debugger to break just before the line where the dll is entered via a call to System.Diagnostics.Debugger.Break();.
I found some instruction on the net regarding stepping into debugging unmanaged code, and enabled the 'Enable unmanaged code debugging' check box, I've also tried turning on the Options->Debugging->Native 'Load DLL exports' and 'Enable RPC Debugging' (even though it's not COM). I've also copied the debug dll and .pdb to the same bin directory as the service.
However the unmanaged code is not being stepped into which is what I really need.
UPDATE: I found the Debugging Type in the DLL properties and set it to 'Mixed' as per suggestion on several sites but to no avail.
UPDATE2: My project now emits the debug dll and the pdb to the same directory as the debug service. Still unable to debug the dll.
Try setting the unmanaged code as the startup project. I know it doesn't make sense but I remember this working for a very similar project.
Since the DLL doesn't have an associated executable, when you try to run it will pop up asking what app to run. Browse to your C# app and then you should be good to go.
Happy debugging!
EDIT: it's been a while, but I think the debugging type Mixed is correct
In the end I created a console app and recreated all the prior calls just to make sure the call would act as it did in the actual service with the actual parameters once it got there.
I chronicled my fix and the resultant code at my site.
There is a workaround in Visual Studio 2013. Run the application from cmd line. When System.Diagnostics.Debugger.Break(); is hit, a Visual Studio Just-In-Time Debugger window should pop out. Check "Manually choose the debugging engines.", click "Yes" and ensure that "Native" engine is checked. Click "OK". Now you should be able to step into the native code as if you would by running the code from within VS.
I have a Visual Studio solution with four C# projects in it. I want to step into the code of a supporting project in the solution from my main project, but when I use the "Step into" key, it just skips over the call into that other project. I've set breakpoints in the supporting project, and they're ignored, and I can't for the life of me get it to step into any references to that project.
Everything is set to compile as "Debug", and I've seen Visual Studio warn me that my breakpoints won't be hit before - it doesn't do that in this case. It's as though it looks as though my code will debug, but then at run-time, there's a setting somewhere that tells Visual Studio not to step through the code in that project. All the other projects in my solutions debug without problems.
What box have I checked to cause this behavior?
UPDATE FOR CLARITY: The "Just my code" option is currently disabled. Also, since the code belongs to a project in my same solution, I don't think the "Just my code" option applies here. I thought it only applied to pre-compiled code that I didn't have the source for, but since I have the source in my project, I don't think this option has any effect.
Not sure if this is it, but "Tools>Options>Debugging>General:Enable Just My Code" is a possibility. (I prefer to always leave this unchecked.)
It turns out that the assembly needed to be copied into the GAC before it could be debugged. Under the debugging option "Just my code", there's an option to suppress an error if you don't have any user code, and it was suppressing the following error:
The Following mobile was built either
with optimizations enabled or without
debug information. (Module name and
path) To debug this module, change its
build configuration to Debug mode.
Since I was building it in Debug configuration, I searched on that error message and got this:
http://claytonj.wordpress.com/2008/01/04/the-following-module-was-built-either-with-optimizations-enabled-or-without-debug-information/
Problem solved. I don't know why it needs to be in the GAC in order for me to step into the project, but it does. I don't ask why, I just ask how, and then I do it...
One thing to check for is that your supporting project assembly has not been installed in the GAC. Open a command prompt and run the following to make sure...
gacutil /l assemblyName
You need to ensure the supporting projects have pdb files or else Visual Studio will not have the necessary information to step through the code.
If you have the source code for the dll's into which you are trying to step into, do the following:
Click on the project in which these dll's are added as reference and remove them.
Add the Project(s) corresponding to the dll(s) to the solution
Right click on the project -> Add Reference -> Choose the newly added Project(s).
Now set the break point and debug the code.. You will be able to step into the code.
The reason for the issue is because you program is still referencing the old dll (without the source code) as it has been added to your project as a reference. Once you remove that dll and add the Project (Source code of the dll) of the dll, Visual studio will be able to step into your code.
A couple of possibilities:
There is a check box to step into "just my code". Its intent is to make it so you can't step into Microsoft's Framework code (unless you choose to by unchecking the box).
You might try recompiling the supporting code to make sure the code you're debugging exactly matches the code file you're looking at. VS does care about this and will disable a breakpoint if you put it in the code file whose version doesn't match. Also, make sure the PDB file is in the same directory as the DLL.
In Visual Studio 2013 one way to cause this behaviour is to set build configuration to Release.
Put it back to Debug and see if that helps.