优先机会异常：RPC服务器不可用

Question

At some point while developing my C# application, the following started to appear in the VS Output pane whenever I create an OpenFileDialog:

First-chance exception at 0x75A6C42D (KernelBase.dll) in (myapp).exe: 0x000006BA: The RPC server is unavailable.

I've been maintaining this application for years, and definitely never saw this before, so I started rolling back in SVN to determine when it began.

Bafflingly, revisions in which it occurs & doesn't occur seem to be inconsistent; if I go back sufficiently far it never happens, but there's an "area" when I can check a revision, it won't happen, I'll check another revision, it will, then I'll return to the first, and this time it suddenly will. In other words, I can't seem to reliably pinpoint when it started happening.

To illustrate this, here's an excerpt of my tests, indented for clarity. Numbers are revisions. For each test, I "update to revision" and do a full rebuild.

      3977: Exception. This is the most-recent revision.
 3839: OK.  Since it didn't happen, I'll start working my way back up to see when it starts
   3843: OK
    3852: OK
     3890: Exception. So it started between 3852 & 3890.
    3852: Exception. Huh?? I JUST tried 3852, and last time it didn't happen!
3778: OK. Going back this far, I've never seen it happen.
    3852: Exception. I guess I'll start working my way BACK to see when it stops.
   3828: Exception
  3810: OK
   3828: Exception.  Just making sure.
  3810: OK. Just making sure again.
   3828: OK.  What?? 3828 showed the exception last time I tried!
    3852: OK. (but previously it showed the exception)
     3890: Exception

I'm aware that I can just tell VS not to break on these types of exceptions, and ignore them. But as mentioned, after years of working on this software, I've never seen it once - so I'd like to determine exactly when and why they started, rather than just turning a blind eye.

Answer 1

This has nothing to do with your project. When you use the shell dialogs, like OpenFileDialog, you load Explorer into your process. Which comes with a lot of baggage, you also get all of the shell extensions loaded. The kind that customize Explorer, they work just as well in the dialog.

Misbehaving ones are quite common. Programmers tend to use the quirkier kind. Any mishap in such a shell extension is now visible to you, the debugger tells you about it.

So, nothing actually went wrong, the exception was caught and handled. Explorer implements counter-measures against bad shell extensions destabilizing it and automatically disables them. So you just have a lame-duck shell extension that doesn't work, low odds you'd notice since it probably hasn't worked for a while.

The debugger can tell you which one is bad. Enable unmanaged debugging and tick the Thrown checkboxes in the Debug + Exception dialog. The debugger will now stop when the exception is thrown. You won't see any source code but you can look at the Call Stack debugger window for hints. It displays the name of the DLL that contain the bad code somewhere on the stack, below the Windows DLL functions. The name ought to give you a hint which one is the troublemaker. SysInternals' AutoRuns utility is excellent to disable them.