CoCreateInstance and Administration privileges

[@í]

Hi,

I have a problem with CoCreateInstance. On the same NT4 SP4 machine I get
different behaviour depending whether I am logged in as "administrator" or
as "user". In the first case CoCreateInstance succeed, in the second case I
get back a REGDB_E_CLASSNOTREG error.
Of course the registration is the same, and I can read the relevant key in
the registry even if logged in as "user".

Any suggestion?

Thanks a lot!!

Paolo

[Girish Bharadwaj [mvp]]

Is this COM object a local server? Or is it an inprocess dll?
If its a local server, see if setting the identity tab in DCOMCNFG to
"interactive user", helps.
Also, see if event viewer has any entries regarding this COM object.

In article <OC8MzECf#GA...@cppssbbsa02.microsoft.com>, "@í "

----
Girish Bharadwaj B.V [vc++/mvp]
Please post Questions in the newsgroups.
Do not mail them to me directly.
Thank you.
---

[@í]

Thanks,

My COM server is a Text-to-Speech engine using MS Speech API, and it is
shipped as a in-proc server (DLL).

The COM interface on which I perform QueryInterface and that is giving
problem was written by me. I wonder whether there is some
setting/registration I should use to make the interface available to
non-administrator user. It seems that if I perform QueryInterface on another
interface (not written by me, but standard Speech API interface) it works
even if the user is not Administrator.

For this special project I really need the user to be forced to Query my
interface first, before being able to operate with the other interfaces.

The DCOMCNFG panel does not list my DLL. Also I am not sure that that would
be the right approach since it would require the final user to run a quite
advanced administration tool. Often users of my application are far from
being expert user of Windows NT.

Do you have any other suggestion?

Paolo

Girish Bharadwaj [mvp] <gir...@mvps.org> wrote in message
news:uX0E0MDf#GA....@cppssbbsa02.microsoft.com...

[Girish Bharadwaj [mvp]]

Can it be that you have an AppID associated with your object? if yes, and if
you are using ATL, it will fail to write stuff in there since only
administrators have privilage to write there.
And that might be the problem. I am guessing here..

In article <ucPKAIAg#GA.267@cppssbbsa03>, "@í "

[@í]

Thanx again,

Well no, I only register the CLSID of my object, that's all. I do not use
ATL nor MFC, I have written this in plain C++. The problem is that the DLL
is not even loaded up when I am not logged as administrator. It seems like
the client application can not access the registry and so it fails to find
the object, though it works perfect when I am logged as administrator.

What's worse, I have another version of my object that is completely
identical, except that it does not include the incriminated interface, with
that object I can successfully call CoCreateInstance (of course with another
interface) and I get no problems.

This problem is confusing me completely...

Paolo

Girish Bharadwaj [mvp] <gir...@mvps.org> wrote in message

news:#GyRX$Bg#GA.269@cppssbbsa03...

[Girish Bharadwaj [mvp]]

Is this object on a network drive?Or a mapped drive?
Is the client on a network drive? Or a mapped drive?
Can you show the code where you are doing the registering?
Do you have your object in a path containing spaces?

In article <eTajg4Cg#GA.263@cppssbbsa03>, "@í "

[@í]

Hi and thanks!

Now I have put my DLL on the root of the C: local drive just to make sure
the problem is not due to the pathname. Also the name is perfect within the
8.3 DOS convention. I still get the same problem, CoCreate Instance works
fine if I am logged with my account (Administrator), and not working with a
test account without Administrator privileges.

My code is the following:

[...]

hRes = CoCreateInstance(CLSID_TTSIvxCustom,
NULL,
CLSCTX_INPROC_SERVER,
IID_ITTSIvxCustom,
(LPVOID *) &pIvxCustom);

if (FAILED(hRes)) // Here I get hRes = REGDB_E_CLASSNOTREG
return NULL;

[...]

where CLSID_TTSIvxCustom is defined as follow:

DEFINE_GUID(CLSID_TTSIvxCustom,
0xa6938f50,0xb586,0x12d1,0x4e,0x7b,0x00,0x00,0xc0,0x73,0x62,0xe4);

and it is registered as follow:

[HKEY_CLASSES_ROOT\CLSID\{A6938F50-B586-12d1-4E7B-0000C07362E4}]
@="Infovox Custom"

[HKEY_CLASSES_ROOT\CLSID\{A6938F50-B586-12d1-4E7B-0000C07362E4}\InprocServer
32]
@="C:\\IvxCust.dll"
"ThreadingModel"="Apartment"

Thanks again!

Paolo

Girish Bharadwaj [mvp] <gir...@mvps.org> wrote in message

news:ezxEuIDg#GA.267@cppssbbsa03...

[Girish Bharadwaj [mvp]]

Can you try doing CoGetClassObject() then calling
IClassFactory::CreateInstance explicitly (instead of CoCreateInstance)..
As is, your stuff looks just fine..

In article <OXljWOEg#GA.160@cppssbbsa03>, "@í "

[Denis Kozhemiakin]

@М wrote in message ...
>[...]

>[HKEY_CLASSES_ROOT\CLSID\{A6938F50-B586-12d1-4E7B-0000C07362E4}\InprocServer
>32]
>@=C:\\IvxCust.dll
>"ThreadingModel"="Apartment"

I am not sure, but why do you use double-backslashe <c:\\...> in path to your server ?

Best regards, Denis Kozhemiakin, Visutech Ltd.

[Denis Kozhemiakin]

@М wrote in message ...
>[...]

>[HKEY_CLASSES_ROOT\CLSID\{A6938F50-B586-12d1-4E7B-0000C07362E4}\InprocServer
>32]

[Michael Nelson]

Because \ is a special character in REGEDIT, putting it in twice tells
REGEDIT to enter a \ literally.

Denis Kozhemiakin <Denis.Ko...@visutechminsk.com> wrote in message
news:OdsYKapg#GA...@cppssbbsa02.microsoft.com...
> @í wrote in message ...
> >[...]
>

>[HKEY_CLASSES_ROOT\CLSID\{A6938F50-B586-12d1-4E7B-0000C07362E4}\InprocServe
r
> >32]
> >@=C:\\IvxCust.dll