0

I've got a situation where I have a callback from unmanaged code to managed C# code. The C# code is throwing an exception and if I let it propagate back through the unmanaged code it gets silently ignored.

In the callback I'd like to catch the exception and then force it to be treated like an unhandled exception - either breaking in the debugger, or aborting the process if not running under the debugger.

What's the best way to handle this? Or, are there any references to discussions about this issue?

(I don't have control over the unmanaged code - it's a Win32 WndProc callback).

aybe
  • 15,516
  • 9
  • 57
  • 105
Brad Robinson
  • 44,114
  • 19
  • 59
  • 88
  • Have you tried https://learn.microsoft.com/en-us/dotnet/api/system.appdomain.unhandledexception?view=netcore-3.1 ? – aybe Jul 12 '20 at 02:19
  • Breaking in the debugger is easy. See marked duplicate. You can then unconditionally abort the process when handling the exception, because the debugger will break before that code is hit (in the debugger you then have the option of skipping past the abort or not). – Peter Duniho Jul 12 '20 at 02:23
  • @Aybe - are you suggesting that I somehow raise that event myself? Not sure that's possible, nor that it would trigger the debugger. ie: I don't understand what you're suggesting I should try. – Brad Robinson Jul 13 '20 at 04:55
  • @PeterDuniho The linked answer is a possible work around but not really what I'm after. I'm after a way to trigger the unhandled exception in the debugger if propagates up to the callback without being handled. Setting first chance handler will always trigger even if something between the exception code and the callback catches it. To be clear I'm not trying to just catch one particular exception, nor debug one particular bug - I'm working on a UI toolkit and want a decent exception reporting/handling/debugging mechanism for when client code throws an exception during one of these callbacks. – Brad Robinson Jul 13 '20 at 04:59
  • I was suggesting that you try do your work in that handler. – aybe Jul 13 '20 at 05:13
  • _"I'm after a way to trigger the unhandled exception in the debugger if propagates up to the callback without being handled"_ -- unfortunately, that goal doesn't make sense. That is, if you look at the situation from the debugger's point of view, it has no way to know what you're trying to do, because from its point of view, the exception _is_ handled, by your callback's handler. You can only either have the debugger break when the exception isn't handled, or also when it is handled. If you are handling it, then from the debugger's point of view, it's handled. Period. – Peter Duniho Jul 13 '20 at 16:27
  • Please note that questions taking the form "best way" or "references to discussions" are both off-topic for Stack Overflow. They both are subjective, invite debate, and fail to be well-defined enough for someone to be able to anticipate what _the_ correct answer is, and there are specific close reasons for both scenarios. You may have better luck by narrowing the question so that it provides a [mcve], a clearly- and precisely-stated desired outcome, and a detailed explanation of what you've tried already and why that didn't achieve your goal. – Peter Duniho Jul 13 '20 at 16:29
  • @PeterDuniho I understand your point but what I was hoping for was a way for the handler to say "I can't handle this, but I can't just throw it because the unmanaged code will silently consume it, so I want to throw it straight to the debugger as unhandled". It seems this just can't be done so the best I can do is either kill the process or call Debugger.Break() if running under the debugger. – Brad Robinson Jul 15 '20 at 05:06

0 Answers0