Visual studio exception settings can break your debugging

Debug deep trouble through Visual studio exception settings. Debuggers are useful. Until they cause errors that only occur when debugging. That’s a pita, because you will still need the debugger.

“My” error occurs in a windows forms application written in c++/CLI (using visual studio) when calling a fileselector’s ShowDialog(). The release configuration works ok, and so does the debug configuration, as long as you press Ctrl-F5 and not F5. I’m leaving out exact version numbers. Everything is late(st), except the dotnet framework (target), which is 4.7.2.

In Debug, an exception was caught by VS which made continuation seemingly impossible. Memory is 32 GB, so I exclude simple hardware insufficiencies. Total usage when fault occurs is about 38% with somewhat over 300 MB for the program.

Error is exception 0x000006BA: The RPC server is unavailable.

Mind, this is not true as everything functions fine, except when debugging. Nevertheless, I ran DISM and SFC resulting in a clean bill of health. The Remote Procedure Call service is running.

My first possibly helpful thought was a shortage of handles or related resources. Symbol loading is virtually excluded (I loaded selectively for the stacktrace). But that is such a general notion that I did not start by following up on it. Which proved just as well.

Callstack:

The exception is not caught by a try-catch block (other thread, probably). I did register exception handlers, but that’s little use here as it is apparently not caught by: Application::ThreadException += gcnew System::Threading::ThreadExceptionEventHandler(&MyForm::OnUnhandled); However, that might be because VS catches it first. But no such thing happens in the other configurations.

After the exception it is possible to continue (F5), the fileselector will be partially shown and explorer will totally hang, requiring a hard reset. Actually, this requires an edit: clicking away the VS exception message (twice) and hitting F5 do allow a correct continuation, but simply hitting F5 will effectively force you to reboot.

This suggests that the excepted thread is part of explorer which also explains why no trace of my app is visible in call stack. My guess is that this is an exception that VS really should not normally catch (unless your app is using the RPC service). And I still think it was a false alert anyway, but can’t construe how that could come about.

Of course, you can adapt the exception settings in VS, i.c. the Win32 exceptions. This exception (0x6ba) is not mentioned, so crossing off was necessary and did the job. You should also be able to specify the module condition for catching, but this does not appear to be seriealized. If you have similar stuff happening to you, think about crossing off exceptions, whether as test or normal settings.

Good debugging!