Launching a COM server from a service on WinXP 64-bit
I have a 32-bit application that gets launched by a service. It is basically an MFC out-proc server. On a 64-bit machine, I am seeing an issue where a client is unable to communicate with this COM server. My assumption is since the application which is 32-bit is getting launched from within a service, there is some kind of a security issue. The COM error I get is 80080005.Is it possible at all to have a service launch a 32-bit out-proc COM server on a 64-bit platform and have an client communicate using COM?Note that all of this works on a plain 32-bit OS i.e. I am able to launch the COM server from within a service and the client is able to connect.
Another piece of data is that if I simply launch the COM server as an interactive process, everything is fine on the 64-bit platform. I set the launch and access permissions from within the code as part of registration and that seems fine on the 32-bit platform. I suspected some problem in this area but nothing that I have tried seems to help.
Anyone have any ideas on this?
Thanks.
[1352 byte] By [
AlBu] at [2008-2-7]
 AlBu wrote: |
| COM error I get is 80080005. |
|
That's "server execution failed". My guess would be that the service in question is running as a 64 bit process and that for some reason trouble is occurring when the service makes the CoCreateInstance call.
That said, I think I would guess that the problem exists in your COM registration rather than in the service itself. Since you are launching an out-of-proc COM server it is COM that is going to actually run the server not your service which is calling the COM object.
You might take a look in the System and Application event logs to see if COM logged any more data on what the actual server execution failure was.
Also, look carefully at what you have written in the registry for your COM object. Remember that in a 64 bit OS you have two sets of COM registration (the real hive for 64-bit processes to use and the WOW6432Node stuff for 32 bit processes to use). Plus, if a 64-bit process cannot find an InProcServer32 or LocalServer32 key in the 64-bit part of the registry it will try and make an out of proc call to the 32-bit COM object - even to the extent of using DllSurrogate (if one is configured) to make an out-of-proc call on an 32-bit InProcServer32 type COM object.
When you look at the registry, where is your LocalServer32 registry key written? Under HKCR\CLSID\{guid}\ or under the Wow6432Node?
| Another piece of data is that if I simply launch the COM server as an interactive process, everything is fine on the 64-bit platform. |
|
Another test would be to write a small VBScript to call CreateObject on your COM object's ProgID. Then, run that script using both \Windows\System32\cscript.exe and \Windows\SysWow64\cscript.exe. The first will run the script inside a 64-bit process and the second will run the script inside a 32-bit process. That will let you test creating the COM object from 32-bit and 64-bit processes without bothering with your Windows Service.
An internal dev named Henry hit this same issue. Here was his response on an email thread:
I hit this _EXACT_ problem a couple weeks ago.
The problem I faced was that I was registering the 32-bit version of the service and having it exist in the SysWOW64 directory. By removing all the 32-bit registration, everything worked wonderfully again.
So, try (manually) doing the following:
Delete any references to your CLSIDs from the following two locations:
HKLM\SOFTWARE\Wow6432Node\Classes\CLSID
HKCU\SOFTWARE\Wow6432Node\Classes\CLSID
Delete any references to your interfaces from the following two locations:
HKLM\SOFTWARE\Wow6432Node\Classes\Interface
HKCU\SOFTWARE\Wow6432Node\Classes\Interface
Delete all the named keys related to your server also:
HKLM\SOFTWARE\Wow6432Node\Classes\FriendlyName
HKLM\SOFTWARE\Wow6432Node\Classes\FriendlyName.1
HKCU\SOFTWARE\Wow6432Node\Classes\FriendlyName
HKCU\SOFTWARE\Wow6432Node\Classes\FriendlyName.1
Hope this helps.
Thanks,
Kang Su Gatlin
Visual C++ Program Manager
Hi,
I have a number of projects where I really run COM objects from a service. It's done by setting LocalService in stead of LocalServer under the CLSID key in the registry, by adding AppID registry keys also, and by calling CoInitializeSecurity.
That last one took me some time to figure out, especially about which parameter values to use, but it turns out you can all pass NULL's and default values, and on Windows 2000 it works fine.
I have tried these services on a Windows 2003 Server recently, and apparently the default security permissions have been tightened. I get the 80080005 "Server execution failed" error when the services want to use eachother's objects.
I haven't found out yet if it's something to do with registry keys missing or set up wrong, something with the COM security settings, file permissions or ACL's here and there, or if it's just something that's no longer possible.
Any help is welcome. I could try deleting the herementioned keys, but on a not-64 bit system I don't think that's the solution.
Greetings
Stijn
Is your question specific to 64-bit programming or are you asking a more general question about COM objects implemented as Services?
The "Server execution failed" error message sounds like the service didn't even run but I suppose it might be trying to say the service ran but faulted before it registered with the SCM as a service. You could try activating the service using the Services snap-in from Administrative tools and teh Start command. If the service faults then you know there's something basically wrong with the code. If the service runs okay then you know the problem is more likely something to do with how the service is launched.
In past OS versions you could set the default Access Permissions and default Launch Permissions for COM objects that were not otherwise configured. Starting with Windows Server 2003 SP1 you can configure defaults and limits. By default the limits should only affect DCOM type remote activation but it might have something to do with your problem, especially if someone changed the launch limits. See this KB article http://support.microsoft.com/kb/892500/en-us
It's about COM in general. But first about what I found out in the mean time: It appears that I forgot about catching the CoInitializeEx and CoInitializeSecurity returned values. The service starts ok, and keeps running ok, but before I discovered CoInitializeSecurity I noticed when an object was created from another process, COM was trying to start the service's exe as an extra plain process. Something that appeared to be fixed by setting the LocalService correctly, not the LocalServer32, but the call I did to CoInitializeSecurity was left in.
Apparently it's only on Windows Server 2003 that the system calls something like CoInitializeSecurity already on a process, which makes my own call to CoInitializeSecurity return an error stating that you can't re-initialize security to anything else.
So finally, I was about to try a build of the services today that don't even call CoInitializeSecurity, which run out-of the box on Windows 2000, and -I suppose- need the permissions set on Windows 2003, like you pointed out.
But then the test-server was acting strangely, remote desktop didn't respond no more, and on the console no property dialogs wouldn't open... strange, I must have broken something i guess... perhaps corrupted some libraries needed for COM. I'll talk about the support guys at work if I can get the machine re-installed... Anyway I'll keep you posted
