Ignore exceptions that cross AppDomains when debugging in Visual Studio 2010
Asked Answered
D

2

11

I'm having problems with debugging an application that calls out to another AppDomain, because if an exception occurs in whatever the other AppDomain is doing, the exception bubbles up and causes Visual Studio 2010 to break no matter what.

I've properly wrapped the method call that throws in a try/catch, and the exception is properly caught when I'm running the application (an ASP.NET MVC application) normally, but when debugging w3wp.exe in Visual Studio 2010, it always breaks on the method call that throws and there's no way I can get past the exception even though it should be caught.

I've tried to decorate the outer method in which the try/catch and throwing method call is done with [DebuggerStepThrough] but that has absolutely no effect. Doing "Continue (F5)", "Step over (F10)" or "Step Out (F11)" does nothing either; Visual Studio just pauses for a bit and then breaks again at the exact same spot with the exact same exception. Once Visual Studio has stopped at the point in which the exception occurs, there seems to be absolutely no way to move on.

What I'm doing exactly is calling assembly.GetExportedTypes() which may throw if an exported type is referencing an assembly that can't be found (a circumstance I want to ignore). The exception thrown is:

FileNotFoundException crossed a native/managed boundary

I'm catching FileNotFoundException properly and as I've said, that works when running the application, but not while debugging. How can I make the debugger understand that I give a rats ass if assembly.GetExportedTypes() throws?

Update:

I thought I had this wrapped up by unchecking the option in Visual Studio 2010 called "Break when exceptions cross AppDomain or managed/native boundaries (Managed only)" (under Debugging > General), but the problem popped up again just now. I've sprinkled [DebuggerStepThrough], [DebuggerStepperBoundary] and [DebuggerNonUserCodeAttribute] on the method in question withuot any effect.

Disposable answered 23/6, 2010 at 14:38 Comment(0)
D
16

There's an option in Visual Studio 2010 called "Break when exceptions cross AppDomain or managed/native boundaries (Managed only)" (under Debugging > General) that, when unchecked, sometimes helps. When it doesn't I need to quit Visual Studio 2010, delete all temporary files, and then try again. Not a very elegant solution, so if anyone have any better ideas, please provide them.

Disposable answered 23/6, 2010 at 14:42 Comment(2)
This fixed my issue in VS 2008 as well as the same issue in 2010. Thanks!Zeph
Thanks @asbjornu. That works with VS 2013 too. This fixed my problem with HangFire Dashboard application. Was working on my laptop but not on my desktop. Laptop had the option unchecked the desktop had the option checked.Follow
M
0

You may be experiencing an issue in the .NET Framework, or Visual Studio, so you can try one of the following:

  1. Uncheck "Enable Just My Code" in Debugger This will make sure that VS will break if an exception is happening in one of your references.
  2. Configure Visual Studio 2013 for debugging .NET framework (same link as #1)
  3. Use DnSpy to debug any assembly. It will give you source code to trace even if it is not available, according to #3 of this article: "7 Debugging Techniques you should know in C# .NET" -- "3. Debug your references with DnSpy". And there are further tips about using dotPeek and ReSharper in a similar way at the bottom of section 3.

Finally, if those don't work, here is one last idea. When you cross AppDomain boundaries, you are using remoting. You can try moving from running in two separate AppDomains to running in two seperate Windows processes. You should still be using remoting, so hopefully it doesn't add too much work. Also, don't forget to let us know any solutions you find on your own.

Maleki answered 29/10, 2019 at 15:48 Comment(1)
I forgot temporarily merging the AppDomains into one. Just create use different Visual Studio solution. Of course, there's a REASON why you're using two different AppDomains... Still, it could be the least painful way to move forward.Maleki

© 2022 - 2024 — McMap. All rights reserved.