Why does my call to Activator.CreateInstance intermittently fail?

Question

I'm using the following code to access the Windows Explorer Shell's band site service:

Guid GUID_TrayBandSiteService = new Guid(0xF60AD0A0, 0xE5E1, 0x45cb, 0xB5, 0x1A, 0xE1, 0x5B, 0x9F, 0x8B, 0x29, 0x34);
Type shellTrayBandSiteService = Type.GetTypeFromCLSID(GUID_TrayBandSiteService, true);
site = Activator.CreateInstance(shellTrayBandSiteService) as IBandSite;

Mostly, it works great. A very small percentage of the time (less than 1%), the call to Activator.CreateInstance throws the following exception:

System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {F60AD0A0-E5E1-45CB-B51A-E15B9F8B2934} failed due to the following error: 80040154.
  at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck)
  at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean fillCache)
  at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean fillCache)
  at System.Activator.CreateInstance(Type type, Boolean nonPublic)

I've looked up the error code, and it appears to indicate that the service isn't registered. I'm pretty sure that's not actually the case since the call will work just fine a few moments later, and the CLSID is provided by explorer.exe.

I'm stumped. What might cause Activator.CreateInstance to fail, but only rarely?

Answer 1

Permissions? Yes, there is a problem with high-integrity applications accessing COM objects in medium-integrity applications. Somewhere at my website there is a demonstration of exactly this. Ah, but for the TrayNotify class, not TrayBandSiteService. I hope you didn't spend too much time figuring out something you might easily just have read.

Anyway, see the last paragraph of this, from which I now quote:

As an aside, note that the program fails if User Account Control (UAC) is enabled and the program is run with elevated privilege. EXPLORER is the COM server and TRAYNOT (my demonstration program) is a COM client. Yet EXPLORER has only medium integrity. Though Microsoft's notes on UAC - they're not really substantial enough to count as programming documentation - deal with the situation of a lower-integrity COM client trying to communicate with a higher-integrity COM server, curiously little is said about the reverse. A higher-integrity COM client is protected from a lower-integrity COM server, much as a higher-integrity program is protected from receiving window messages from a lower-integrity program. For the latter, Microsoft provides the higher-integrity program with explicity means to open itself to expected messages from a lower-integrity source. Finding the analogous provision for COM may be a worthwhile exercise for another time.

I regret to say I have never found the time.