Why is Debugging Including External Library Code

Viewed 659

This has been around forever, but I wonder if anyone has ever found a solution...

Sometimes I disable "Just My Code" (these days in conjunction with enabling SourceLink) and turn on "Break When Thrown" for all "Common Language Runtime Exceptions" in Visual Studio because I want to check for issues where exceptions are swallowed by a third party library.

After I'm done and RE-ENABLE "Just My Code", AND leave "Break When Thrown" for all "Common Language Runtime Exceptions" enabled, I sometimes STILL break when third party libraries throw HANDLED exceptions. Meaning, the third party library has a silent exception that I don't want to see, but Visual Studio breaks anyway. For example, the library might have an expected TCP connection timeout, but Visual Studio breaks anyway. I would only expect this to occur when Just My Code is DISABLED.

Usually I have to restart Visual Studio and sometimes clear all cached debugging information which slows down other stuff.

Has anyone found a way around this?

UPDATE: see screenshot demonstrating unexpected behavior. Just My Code is enabled, Break When Thrown is checked, and a handled exception in third party code is popping up anyway. If I restart Visual Studio (and sometimes clear the cache too), I stop getting prompted using the same settings. Seems like something is making that external library be considered "My Code" even after I disable Source Link.

enter image description here

Thanks.

1 Answers

The reason is very simple and is stated in Microsoft docs article Specify whether to debug only user code using Just My Code in Visual Studio. Notice this:

Exception behavior

If an unhandled exception occurs in non-user code, the debugger breaks at the line in user code where the exception was generated.

If first chance exceptions are enabled for the exception, the user-code line is highlighted in green. The call stack displays an annotated frame labeled [External Code].

And also this in C++:

Exception behavior

When the debugger hits an exception, it stops on the exception regardless of whether it is in user or non-user code. The User-unhandled options in the Exceptions dialog box are ignored.

When you reference a third party library, It becomes embedded in your .pdb symbol Thus, making it a part of code. When you debug 'Just My Code' the debugger knows that it will not break on any 'un-managed code' by you but it will break when unhandled exception occurs on third party libraries.

There is a way to surpass it (look at article .pdb symbol i.e.), you can specify which one of your modules will be included in your .pdb file. This might solve your issue, tough I didn't test it myself yet.

Regarding your statement:

Usually I have to restart Visual Studio and sometimes clear all cached debugging information which slows down other stuff.

That's true, because then the visual studio has to write the .pdb symbol again, so you are good for one time or two at most and then back to the unwanted behavior.

My guess is that Microsoft wants you to be notified for unhadled exceptions, even in third party libraries, when you debug unless you specify something else explicitly just so you will be aware for the problems in your code.

Related