Hi,

This question is a repeat (kind of) of questions found all over the
net, and one which I'm struggling with right now. The question seems
never to have been answered.

I have a COM component written using VS.NET C++, as an attributed
SERVICE module. I want a singleton instance of this component to be
available to many other applications, and thus have decided to
register an instance of this object on the Running Object Table. I
want to be able to dispense this instance to all comers, by querying
the ROT with _com_ptr_t::GetActiveObject. This technique works OK when
the object is registered by an in-proc server, but returns an
0x800401e3 operation unavailable error when attempting to access an
instance registered from a service.

This problem seems to be perennial. I have found similar questions all
over the net dating back till at least 1998. It seems to be related to
security issues. Unfortunately, while the question has been asked many
times, it has not been adequately answered in a forum that people will
find easily. Hence this question.

The Offending Code:
===================

STDMETHODIMP CRbacACDispenser::GetInstance(IUnknown** ppunk)
{
  IUnknownPtr spunk;
  HRESULT hr = spunk.GetActiveObject(/* vi_progid */);
  if (SUCCEEDED(hr))
  { // yay! we got it off the ROT
    *ppunk = spunk;
  }
  else
  { // not on the ROT? perhaps this is the first request...
    spunk.CreateInstance("rbac.AccessController2");
    hr = RegisterActiveObject(spunk, __uuidof(IAccessController2), 
ACTIVEOBJECT_STRONG, &rotHandle);
    if (SUCCEEDED(hr)) // well its definitely on the ROT now!
    {
      *ppunk = spunk;
    }
    else               // doh! Something catastrophic went wrong....
    {
      *ppunk = NULL;
      return E_FAIL;
    }
  }
  return S_OK;
}


What I know already:
1. Error returned on calling spunk.GetActiveObject is "0x800401e3
Operation unavailable".
2. DCOMDNFG settings tried:
	Authentication level == none
	Access Permissions == Everyone gets full control
	Run application as == My login ID
3. I'm fairly sure it's a security setting that needs to be set
properly, but can't find any docs on how to find out what's wrong

Do you have an answer for this question, or can you give me pointers
to places on the net where I can find the answer myself. In the case
of the latter, I'll write it up and post the full answer later. If on
the other hand, you have a better way of solving the porblem, I'd be
even more pleased to hear from you, cos this is driving me mad.

Thanks in advance,

Andrew Matthews
WebServer ltd, UK.

---

Request for Question Clarification by mathtalk-ga on 10 Nov 2002 14:26 PST

Hi, Andrew:

Would you please clarify:

1) if the service that registers the object is running under a
usercode

2) if the object appears in the ROT as verified by either of the ROT
viewer tools I mention in my comments

thanks, mathtalk-ga

Hi, Andrew:

Your suspicion about DCOM security settings is understandable (esp.
because the magic of DCOM configuration rarely is), but they might not
be at fault in this particular case.

The obvious search at support.microsoft.com turns up this Knowledge
Base article:

[Q238610 - PRB: GetObject or GetActiveObject Cannot Find a Running
Office Application]

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238610&

in which the culprit turns out to be a delay in getting the objects
actually registered in the Running Object Table (ROT).  Since you have
(it looks like to me) really opened up the security permissions in
DCOM settings, I'm inclined to wonder about independently verifying
the objects listed in the ROT.  Sounds like a technique that would be
interesting, if not useful, in its own right.

The explanation provided by Microsoft is that in this case Office
applications don't immediately register some of their COM objects, and
the workaround provided is along the lines of playing with the
application focus and allowing for a delay in registration by
"polling".  The article gives some code for this in both VB and C++.

I'll be interested to see what you and other experts can pull
together, while I research the inspection of the ROT...

regards, mathtalk-ga

Hi mathtalk-ga,
Sadly this is not the answer for my problem. If you examine the code
in the question you'll see that the dispenser is lazy, but not too
lazy. i.e. it creates and returns an instance pointer on the first
request, and then dispenses that instance thereafter. Unfortunately,
the component has no windows and thus no focus (it's a service), so it
won't work using this technique. And, it's not an Office app, so the
same rules don't apply anyway.

aabs

Hi, Andrew:

I understand that your application, being a custom out-of-process COM
server, running as a service, will require a different resolution.  My
suggestion is a ROT viewer application might make sure the particular
moniker you create your singleton instance under, is there as you
expect it to be.

I found such a viewer (written by Greg Lorriman in Delphi) at:

http://www.lorriman.com/software/rotviewer/rotviewer.htm

and downloaded it, scanned it with McAfee VirusScan, and unleashed it
on my WinXP laptop.  Seems to work.

MS puts a different ROT viewer (VS 6.0 and VS.Net) called
Irotview.exe, in C:\Program Files\Microsoft Visual Studio
.Net\Common7\Tools\Bin on my machine.

regards, mathtalk-ga