My C# debugger is not working properly. It skips break points and line of codes sometimes. I have checked the configuration manager. I have even tried adding my projects to new solution files. Can someone please help me?
My debugging checklist:
Make sure your attaching to the process using the correct code type - if your process has both unmanaged and managed code then dont rely on "auto" to work for you, explicitly state what sort of code your trying to debug
Goto the modules window (Debug -> Windows -> Modules, you may need to enable it in the "Customize..." menu
Check to make sure that the assembly your trying to debug has been loaded, and that symbols have been loaded - if they haven't been loaded then right click on that module and select "load symbols"
Open your code file and place your breakpoint - if it appears with the little warning symbol then look and see what it says,
You might need to goto "tools -> options - > debugging -> general" and untick "Enable Just My Code (Managed Only)"
You might also want to uncheck "Require source files to exactly match the original version", if you think your sources might be slightly out (beware however, as this can lead to you debugging with completely the wrong sources, which can be very confusing)
On certain cases you might find that your module doesn't get loaded at the point where you attach your debugger (for example if you have some sort of plug in archetecutre, and plugin assemblies are only loaded when you first use them). In these cases all you can do is try and make sure everything is prepared ready for when the module is loaded.
Make sure optimizations are disabled (this is the defaut for the Debug configuration, but they are enabled in Release configuration). Compiler optimizations can mess with the debugger...
Are you sure that it compiled correctly? It sounds to me like you're debugging against a previous version, which can happen if the build fails (perhaps a code bug, perhaps the files are readonly).
If entire methods are being skipped, look at the source and see if the System.Diagnostics.DebuggerStepThroughAttribute attribute is present.
Despite the name, it PREVENTS the debugger from stepping through the method.
This worked for me in VS 2017, Go to Tools > Options then under the Options Window go to the Debugging section. Enable - "Enable .NET Framework source stepping"
This sounds like your source code is out of sync with the PDB files. The easiest solution is to clean the solution (which deletes all your dlls from the bin folder). Recompile, and then try stepping through again.
If it still fails, try closing the solution and deleting the "obj" folders. And then try again.
And also check you are compiling in debug mode - something I've done often ("why isn't it stepping through?!")
not getting break point
If at least sometimes the break point is hit it means that all the settings are most probably OK.
The missing hits may be caused by some side-effects, for example: property evaluation by the debugger (at least VS skips the breakpoints during the property evaluation for debugger) or some spying tools (but these are usually catch by debugger).
If you think this may be the case, turn off the spying tools and disable the property evaluation by the debugger.
This may be sometimes not enough, for example: If your property returns a collection, displaying e.g. a Count() will evaluate the property - so remove also all references of property from the watch windows, etc.
Disabling "Project Properties/Build/Optimize code" worked for me.
#Justin's answer above was super helpful. I would add one thing to the list.
Check to make sure you're running in debug and that your debug preferences have "Optimize code" unchecked. See below:
Also make sure that the code you're trying to debug is running in the same process as the main executable. I just wasted a half hour figuring that one out - the breakpoint wasn't hitting because the code of interest had been spun up in a child process instead of being called directly (the program in question has two different modes of operation).
If you're getting this kind of error:
The current .NET SDK does not support targeting .NET Core 2.1. Either target .NET Core 2.0 or lower, or use a version of the .NET SDK that supports .NET Core 2.1. DCR_Parser
Right click on the project in solution explorer and click on Properties. Under the Application tab go to Target framework .NET Core 2.0. And save.
Related
I wanted to be able to step through/debug the source code of the .Net Core framework, since it is open source now and everything.
So I followed some answer on here, or something, but I've forgotten exactly what I did.
The problem is that the loading of the symbols took forever each time I started debugging and, worse, Visual Studio would no longer break on most exceptions and whenever there was some issue it would break but show me the exception in some esoteric class or file that I, presume, is part of .Net Core even though I know the actual exception is being thrown in my own code.
So, now I want to fix that and have the symbols loaded once and then used from the cache and VS breaking on exceptions like it should normally.
Failing that I'd like to undo whatever I did but, like I said, don't remember exactly what I did. Here's what I think I did:
Go to Tools -> Options -> Debugging -> General and check the following options:
Enable .Net Framework source stepping
Enable source server support
and unchecked:
Require source files to exactly match the original version.
I also have both "Microsoft Symbol Servers" and "Nuget.org Symbol Servers" in my "Symbols" section and the option "Load all modules, unless excluded" selected.
So, how can I still step through .Net Core source and have VS behave like normal with exceptions and not load symbols for 5 minutes every time I start debugging
-OR-
How do I undo any options to have everything like before?
We are building a solution for Release, but when attempting to attach using studio 2010 professional, no thread is showing any stack information, nor any breakpoint can be set, etc.
The goal is to be able to attach the Visual Studio/JIT Debugger to the running process while having as many optimization benefits as possible.
Most of our searches comes down to 'compile with debug:full' and you will be able to debug, but that doesn't seem to be the case, I thing that the JIT optimizes the code in runtime and thus we cannot debug, is this true?
Is it possible to compile and tell the JIT to downplay the optimizations and allow debugging? (while retaining other optimizations)
UPDATE
using #HansPassant's answer, I looked at the modules and saw that although the pdbs are in the same directory as the binaries, indeed no debug symbols were loaded. what I also saw is that the my libraries are marked as 'User Code'-'NO' which is probably the reason it was not loaded automatically.
By loading symbols manually AND disabling 'just-my-code' I was also able to set breakpoints and see stacks.
Question now: why is my code not marked as User Code? is this normal behavior? can I configure this to my assemblies in some way to avoid this?
Debugging optimized code is no great pleasure. You certainly may have trouble setting breakpoints, a method may have been inlined. And inspecting local variables and method arguments is liable to make the debugger sulky when the variable was optimized to be stored in a cpu register.
You however certainly can still inspect call stacks, you'll see the methods that didn't get inlined in the stack trace. Basic mistakes you might make:
when you attach a debugger, you get the option to select the debugger type. Be sure to select "Managed", you will not have much use for the native debugger
be sure that you are looking at the correct thread, the program can be broken at an arbitrary location. Use Debug + Windows + Threads to select the appropriate thread
be sure that you are actually broken at a location in your code. You can easily end up inside a Windows operating system DLL or a framework method, there will be very little to look at when that's the case. Tools + Options, Debugging, Symbols and enable the symbol server so that stack traces that start inside Windows will be accurate
the debugger must be able to locate the PDB files. Use Debug + Windows + Modules, you'll see the assemblies loaded in the process. First make sure that the one you want to debug is actually loaded. Right-click it and select "Symbol load information". It shows you where it looked for the PDB file
the "just my code" option can get in the way heavily, you are very likely to run into significant chunks of code that are not yours. Tools + Options, Debugging, General and turn that option off.
Thought I'd follow up with an additional answer regarding your updated question to help others.
From Microsoft:
To distinguish user code from non-user code, Just My Code looks at symbol (.pdb) files and program optimizations. The debugger considers code to be non-user code when the binary is optimized or when the .pdb file is not available.
I've created a DLL with a Class Library Project with some classes. While adding this DLL as a reference in another projects and debugging, when going step by step or when the class returns an Exception the code from the class is shown.
How can I hide this? I want the exception to be shown on the class instruction, not inside and allowing to see al the code. And when debugging by steps, I want to do the methods without steping inside the code of the method.
Just like if you step through str.Split(), for example. You don't see the code and all the steps. You just see the error on that line or jumps to the next one.
For example:
Dim myObj As New myClass.SomeObj()
myObj.MyMethod()
I do not want the code inside MyMethod to be shown.
Add on the specified method a DebuggerStepThrough attribute to prevent step into. If an exception occures, the debugger breaks at the method call, not inside the method. See MSDN
The behavior you describe is a convenience. It allows the caller to see exactly what is going wrong by looking at the details of the code he's trying to consume. Microsoft even supports this for the .NET Framework source, and it's rather useful in my opinion. I'm not really sure why you'd want to disable it. You can always just use F10 (Step Over) instead of F11 (Step Into) when debugging so that the DLL's code remains available in case you ever need it.
But if you are sure that you don't want to be able to step into any code from the DLL, you need to make sure that the debug symbols are not available to the client application. Visual Studio generates these symbols in the form of a PDB file, which contains the location of the source files and mappings between the generated code and the source lines.
Contrary to some of the other answers, the generation of debug symbols is unrelated to whether the code is optimized (e.g., a "Release" build). I've written about this before in the context of why you might want symbols for an optimized build, but the point is that these are two orthogonal settings. You can turn on optimization and turn off symbol generation, and vice versa. Suffice it to say that I strongly recommend generating debug symbols for all builds.
You can disable the generation of debug symbols in the project's properties (it's hidden under the "Advanced..." button), or you can just move the PDB files to ensure that the client application cannot locate them when debugging. By default, a build places them into the same directory as the binary output, so that when you add a reference to the DLL, Visual Studio finds them easily. If you move either the symbols or the binaries, it won't be able to find them. (The debugger also searches the symbol path, but your symbols probably won't end up there.)
I just had a look at previous questions on topic, but I've got some strange results.
First of all, I followed and used the method that Scott Hanselman proposed in a old post in his blog: http://www.hanselman.com/blog/HowToProgrammaticallyDetectIfAnAssemblyIsCompiledInDebugOrReleaseMode.aspx
Thus, Using the IsJITOptimizerDisabled I'm supposed to check if a particular DLL has been compiled in release mode or in Debug mode.
The strange thing is that I just tried it, built a simple App that check that property and notify the assembly inspected is in debug or in release mode. Checked the results and everything it's ok against two dll I already compiled in both modes.
Then I passed that simple app to a colleague that confirm that in his workstation the results are as expected, the Debug dll show "Debug", the release show "Release" (those two dlls are contained in the same zip of the simple app).
But, when he tries to check those dlls with that simple app in another server (via mstsc) for both of the dll the simple app show "Debug" (even if opening the DLL with ILDASM everything seems fine and some specific methods contained inside a "#if DEBUG" region are not present in the Relase dll).
Now, I'm going mad, is there some reason behind this issue? Am I just too old to see what's going on ? Could be the reflection somehow dependant among the environment? Is there some Service pack that solved a similar known issue ?
Cheers,
Gianluca
The DebuggableAttribute is an attribute which is not compiled into the IL code contained in the executable assembly. It is inserted by the runtime when the assembly is loaded. The creation of the attribute might be affected by environment settings.
For example, a profiler being enabled on the system might have created environment variables or Registry settings that affect the debugging flags. A thread on the MSDN forums suggest to check for environment variables named COR_* or Registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework (and possibly HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework as well).
Using Assembly.LoadFrom() is not a very good idea in this specific case. Use fuslogvw.exe to find out why your program loaded the wrong assembly. GAC, probably.
Anyhoo, LoadFile() is called for here.
I am trying to debug a unit test. When I step into the code of the class I want to test VS2008 show the disassembly rather than the source. I have checked in the modules window and the status for the module in question reads "symbols loaded" so everything looks OK
The project is c#, I am using Visual Studio 2008 SP1, anyone got any ideas, it is driving me nuts!
Symbols and source code is not the same thing. You need either have the source code for your module in the same place on disk it was on the build machine, or set up the source server: http://msdn.microsoft.com/en-us/magazine/cc163563.aspx
If you right click in the source window, there will be a context menu option "Go To disassembly". That will show you what your looking for. Though, typically most people tend to ask how to get to source code from disassembly, not how to get to disassembly from source code! :)
#Grzenio is correct in that if you have the source and symbols and are still seeing dissassembly, something is out of whack.
Try checking for versions of the dll in the global assembly cache (GAC). You might also find other clues by checking the properties of any custom dlls that have been referenced. Specifically the properties "Specific Version" and "Copy Local". If either of these values are true, it could be a clue that the project references a GAC'd copy of a dependency dll.
Old post, but had this issue recently...
Delete the reference to the project for which you want to step through from the project calling the reference. Clean the solution, rebuild everything (which I like to do one project at a time when I have this issue). Add the reference again - ensuring you are adding the reference as a project reference and not directly referencing the .dll.
You can also try going to the debug settings and uncheck "Enable address-level debugging" under Debugging | General.