I am having a nuisance problem with a C# app. To simplify the scenario, I have a main .exe project which references another C# library as a direct DLL dependency. This DLL throws exceptions in a particular place, and the debugger is breaking on those. However, the exception is handled and not re-thrown. My exceptions dialog in VS is checked to only have the debugger break on User-Unhandled exceptions of this type (InvalidOperationException), yet it is still breaking.
However if I link the same library as a project reference (rather than to the compiled DLL) the debugger no longer breaks on this exception.
As well, if I run the .exe program directly (outside the debugger) I see no evidence that this exception is not being handled as I expect. No errors, and my logging indicates the expected control flow.
The related code has been mostly unchanged for some time, but I have refactored my solutions and projects; I was previously using only project references, so perhaps never spotted this issue until I went to DLL references.
Can anyone suggest anything else I might look at as to why the debugger is breaking on this handled exception?
I did some more googling and fiddling, and I have settled on the idea that it seems the 'Enable Just My Code' is what is causing the debugger to break
This link gave me some clear insights into how this option affects the Debugger: http://www.jaylee.org/post/2010/07/05/VS2010-On-the-Impacts-of-Debugging-with-Just-My-Code.aspx
Related
since I am using vs 2017 I am missing one of my most used features I was using in vs 2008 and 2010.
In previous Visual Studio versions you were able to setup exception handling.
VS2010 for expamle:
Debug=>Exceptions=> CLR Exceptions => Thrown checkbox
When I checked this checkbox he would break on every exception which was thrown (did not matter if handled or unhandled). This was a huge bonus because in bad code were logging was very bad you allways found the issue pretty fast.
Now I am working on a project with pretty bad logging and I am getting a lot of exceptions in the output window but not in the log. But I simply can't find the damn code line and the studio debugger is not breaking at the exception.
I found this this and checked "all exceptions in this list". But it did nothing and the studio just ignored it. I am desperately looking for that good old "thrown" features from 2010. It obviously has to be a handled exception.
Anyone knows where I find that must have feature in this new fancy studio?
Best regards
The provided solution here does work. I did not work in my case because he had and still has issues loading the debug informations of other libraries. If you have similar issues, make sure that he has loaded the necessary debug informations. I am not working with project references because of the project size. We are working with post build events which do copy the output libraries to a common directory which we are refering to as reference path. In my case deleting the libs there and rebuilding them did the job. He loaded the debug informations correct and was able to break even at handled exceptions.
Best regards
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 have a severe problem with mixed debugging in MSVC2013. After a call to a COM method from a native C++ DLL, debugger does not stop at breakpoints any more.
Code structure
The picture above presents the overall structure of the code.
I have a single solution with about ten C# projects, about fifty C++ native projects, and one C++/CLI project serving as a bridge between managed and native worlds. Startup project is a C# WPF project (GUI Application), it calls C++/cli project (Bridge) internally, which in turn calls various native C++ Dlls (Various libraries). Alternatively, I can make a C++ console application (Service console app) as startup project for testing purposes only.
I have implemented a library to import some information from Autodesk Inventor document files. Inventor Apprentice COM server (Inventor Apprentice on picture) is used to achieve it, which was freely downloaded alongside with Inventor View 2015. As a first step, the import was implemented in a standalone native C++ console application, and everything worked fine. Then it was adapted to be used in the whole infrastructure as a native C++ dll (Import library), and the debugging hell started.
Symptoms
"debugging broken". In a debug build, after calling the following COM method in Import library:
auto pComponentDefinitions = pDocument->GetComponentDefinitions();
breakpoints in C++ code are no longer hit. Even if I set a breakpoint in the code of another DLL, it is not hit. Breakpoints still visualize as full red circles, so this is not related to PDB issues.
The application itself continues to execute, and some time later I can see the correct results of data import visible in GUI, meaning that Import library has executed correctly. After that, I can pause the GUI Application with Break All button, in which case the main thread is shown stuck deeply inside one of the Inventor's dlls (rse.dll), which cannot be true because that thread has finished import and has even returned correct results.
In the Output window, I can see the following messages, appearing during the problematic COM method call (access violations seem to be normal in Apprentice):
First-chance exception at 0x000007FEDD451F0C (rse.dll) in GUIApplication.exe: 0xC0000005: Access violation writing location 0x000007FFFDE3AFCC.
The Common Language Runtime cannot stop at this exception. Common causes include: incorrect COM interop marshalling and memory corruption. To investigate further use native-only debugging.
First-chance exception at 0x000007FEDD455F6C (rse.dll) in GUIApplication.exe: 0xC0000005: Access violation writing location 0x000007FFFDE3EE6C.
I have tried to embed breakpoints into the code at the moment of compilation, by inserting __debugbreak() before and after the problematic import code. The first one is hit (if debugging is not yet broken), but the second one is not. On the other hand, debugger clearly notices it, because it writes the following message to Output window:
The process hit a breakpoint the Common Language Runtime cannot continue from.
This may be caused by an embedded breakpoint in the native runtime or a breakpoint set in a can't-stop region.
To investigate further, use native-only debugging.
Google gives no results at all for this diagnostic message. It sounds like MSVC thinks it is debugging managed code, which is actually native.
"crashes in call". In case of release build, running the application in mixed debugging mode results in a crash inside rse.dll during the problematic COM call.
Reproducibility
I use MSVC 2013 update 4. Project is built in x64 mode. Net Framework v4.0 is used. Inventor Apprentice from Inventor 2015 is used.
Experimentation shows that:
Everything is OK when no debugger is attached.
Everything works correctly (including debugging), when native-only debugging is used (either via Service console app or after attaching to already running process in native only mode).
In mixed (i.e. native + managed) debugging mode the problem reproduces regardless of whether GUI application was started with debugging or debugger was attached to a working process.
There is a problem both in debug and release modes, but it acts differently. In debug build crazy debugging issues arise ("debugging broken"), but in release it simply crashes somewhere inside ("crashes inside").
Full list of runs performed can be seen here.
The main question
Has anyone seen similar behavior before? What may be the cause of such behavior? Is there a way to fix it?
Disabling the new managed debugging engine of MSVC has helped to fix the issue. It can be done by going to Tools > Options > Debugging > General > tick "Use Managed Compatibility Mode".
While trying to find a workaround for the issue, I have posted the following question. Hans Passant has posted not only a workaround, but also a solution to my main problem. It seems that new debugging engine is not properly working in case of C++/CLI interop.
P.S. Given that the symptoms are quite unique and crazy, I decided to post the full question with the answer, hoping that this information may help some people with similar problems in future.
I'm getting an "System.NullReferenceException: Object reference not set to an instance of an object." Error when I launch a release build of my web application. It tells me to do a debug build to get more information, but when I launch the debug build the error no longer occurs. Without the help of the line numbers that are given with most errors in debug builds it is very hard (from what I know) to pinpoint the cause of this vague error.
Can anyone point me in the right direction to narrow down the cause of this exception?
Thanks.
As a quick remedy to your problem (if you don't have time to rewrite your code), please see the Event Log on the machine where you released the application. There is a big chance you're simply missing some dlls.
As a long term solution, I think you can start with adding some logging functionality to your application (Enterprise Library, log4net, etc. or even your own logger). Printing a complete stack trace is an invaluable source of help especially when you include the .pdb files in your release version. This will allow your executed code to tell exactly which line threw the exception.
Hope this helps,
Piotr
It is possible to get file names and line numbers in your stack traces even if you build in Release mode. See Display lines number in Stack Trace for .NET assembly in Release mode and Is stacktrace information available in .NET release mode build? for example.
In general, I think you should avoid introducing different program behavior in Debug versus Release mode (but maybe you didn't introduce that deliberately?).
I am using a third-party DLL. For some particular cases, a function in the DLL is throwing an exception. Is it possible to debug the DLL in the Visual Studio?
After the answer from Andrew Rollings, I am able to view the code, but is there any easy way to debug through the code in Visual Studio?
If the DLL is in a .NET language, you can decompile it using a tool like .NET Reflector and then debug against the source code.
Or you could ask the vendor if source code is available. That's probably the easiest way.
Building on Andrew's answer, you just treat the decompiled source code as a new library within your project and set breakpoints in the source. Remove all references to the 3rd party DLL so that it is the decompiled code that is executing.
Other things:
You may be breaking the law by decompiling the code, or breaching a licensing agreement with the 3rd party vendor. Make sure to review this with someone.
You will want to make sure that you remove references to your decompiled version if you are shipping to other developers, or checking into a larger source tree. Easy to forget this!
There are two methods I've come across:
1) Accessing the DLL project from the using project.
This involves building the DLL in a separate instance of Visual Studio and then accessing the DLL through a different project in Visual Studio (this assumes you have the source code).
There a number of ways to accomplish this:
You can add Trace.WriteLine
statements in the DLL that will show
up in the 'Output' window in Visual Studio.
You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When
running the calling project in Visual Studio,
program execution will stop there.
From here you can add access the
call stack (including all function
calls in DLL itself) and set break
points (although the icon for
the breakpoint will appear disabled
and the hover text for the break
point will read "The breakpoint will
not currently be hit. No symbols
have been loaded for this document").
If the DLL is throwing an exception (which you can see from
the 'Output' window if the exception
is caught and handled by the DLL)
you can tell Visual Studio to always break when
that type of exception is thrown.
Hit Ctrl + Alt + E, find the type of
exception being thrown, and click
the 'Throw' column for that
exception. From here it is exactly
as if you had used
System.Diagnostics.Debugger.Break()
(see above).
2) Attaching a using process to the DLL project.
This involved hooking the Visual Studio debugger into a running process.
Open the DLL project in Visual Studio.
Run an application that uses the DLL (this
application can't be run from
another instance of Visual Studio since the
process will already have a debugger
attached to it).
From here you can add break points and step through
the DLL code loaded in Visual Studio (although
the break point will appear disabled
the same as in method 1).
Something that has worked for me with debugging a couple of third-party libraries as well as .NET itself is WinDbg. It is an awesome debugger from Microsoft that I have used to troubleshoot some sticky problems that were occuring deep inside the framework.
You need to use the Son of Strike (SOS) extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assembly/CIL instructions to be good at using it. You should be able to determine the exception and what is causing it. We have used WinDbg/SOS to find for instance that in HttpWebResponse, if you are using Gzip compression to download a page and the server returns a bad Gzip header, .NET runs the decompression in the threadpool and a crash will take out your process. Happy debugging.
One more option we should mention here is dotPeek 1.2 (a free decompiler from creators of ReSharper). Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program
As Cesar Reyes mentioned in Stack Overflow question Visual Studio - Attach source code to reference, ReSharper 5 (and later) has this capability.
.NET Reflector 6 comes with a Visual Studio Addin that lets you use Visual Studio's step-through-debugging on assemblies that you don't have the source code for.
Have a look at this blog post:
http://www.simple-talk.com/community/blogs/alex/archive/2009/09/22/74919.aspx for more details.
This is still a very early build. So no guarantee that it'll work, and it might break your visual studio configuration or project configuration. Make sure you have backups (or source control) for any projects you use this on.
Download here:
http://www.red-gate.com/MessageBoard/viewforum.php?f=109
I thought .NET Reflector got some debugging plugins. That'd be a so much better idea because decompiling and recompiling code generally fails, and you need to do so many changes in the code to fix it.
Give .NET Reflector debugger a try. It might help you a lot.