Registration-free COM not working on Windows Server 2003

Question

I have created the necessary manifests for my COM server DLL and a client application to work registration-free in Windows XP. I've tested all kinds of combinations (with and without a registration) and in all cases the client application sees the side-by-side version of the library if the manifests are present, and the registered one if not (or a COM error if there is no registration at all). I've tested on my Windows XP development machine, and given the files (DLL, client EXE and one manifest for each) to co-workers, who've also run everything successfully on their own Windows XP machines. The manifests are external XML files, not embedded resources. So far, so good.

However, when I copy the files to a Windows Server 2003 machine, it doesn't work. I get a silent failure, but an application error in the Application Event Log (see below). If I unregister the DLL and remove the manifests, I get a similar error (silent at the command prompt, but an application error in the event log). Obviously there is some problem finding the registration. I have reproduced this on every Windows Server 2003 machine I can access at our company. According to the Microsoft documentation on side-by-side/registration-free COM, it's supposed to work on Windows XP and later, and Windows Server 2003 and later.

To be clear, the same client runs perfectly on those same Windows Server 2003 machines against a registered (i.e., using regsvr32) version of the same COM DLL, under the same login credentials I'm trying to use for registration-free COM. In other words, there are no intrinsic issues masquerading as registration-free COM problems - this client and server operate fine when the server is registered globally in the registry.

Anybody have any ideas of how to investigate further? I'm not an expert on Windows Server, but is there perhaps some policy setting that would need to be changed to enable this support? If I can locate the necessary change, our tech support/infrastructure people will probably have no probably doing it, but I can't rely on them to research the issue too as they are swamped.

In case it matters (I don't think it should, but you never know) the DLL is written in Delphi 2007, while the client is written in Visual C++.

Event Type: Information
Event Source:   Application Error
Event Category: (100)
Event ID:   1004
Date:    5/2/2009
Time:    8:07:45 AM
User:    N/A
Computer:   ***server name****
Description:
Reporting queued error: faulting application ***program name***.exe, version 0.0.0.0, faulting module ***program name***.exe, version 0.0.0.0, fault address 0x0002ac9e.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Answer 1

With a COM server created in Delphi 7, I have seen similar problems if the COM server was unregistered and the client application started under a restricted user account, because Delphi's COM implementation always tried to update the registration information, even when the DLL's RegisterServer function was not explicitly called.

To see whether this is a problem, attempt to run the client application on an account with unrestricted administrative privileges.

MSDN mentions, that under Windows 2003, problems with registration free COM servers should be detailed in a specific section of the system event log:

When troubleshooting registration-free COM issues, the Event Viewer on Windows Server 2003 is your friend. When Windows XP or Windows Server 2003 detects a configuration error it will typically show an error message box titled for the application you have launched and containing the message "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." I advise that whenever you see this message you reproduce the problem on Windows Server 2003, consult the System Event Log and look for events from the SideBySide source. The reason I don't suggest that you look at the Windows XP Event Log in these cases is that it will invariably contain a message such as "Generate Activation Context failed for [path][application filename].Manifest. Reference error message: The operation completed successfully," which doesn't help identify the problem. http://msdn.microsoft.com/en-us/library/ms973913.aspx#rfacomwalk_topic6

Also, if possible, tell us the file names and contents of the manifest files you use.

Answer 2

One thing to look for is that whether the exe has an internal manifest. In XP, the exe manifest search order is external then internal. In Server 2003 and later, the order is internal then external.