I’ve developed a server application using C# that integrates with a COM object provided by an external source. Here's a high-level overview of the application and the issue I’m encountering:

The application creates an instance of the COM object using Activator.CreateInstance. The COM DLL was supplied by an external vendor, and I am incorporating it into my service application to interact with the database. Specifically, the application uses the methods provided by the COM interface to insert data into the database.

Problem: When I run the application in debug mode within Visual Studio on my local machine, everything works as expected, and the COM object is instantiated without any issues. However, after building the application in release mode and deploying it to the server, I receive the following exception when attempting to create the instance of the COM object:

COM error initializing (HRESULT: -2146768289):
Retrieving the COM class factory for component with CLSID {F6A3408C-5652-45A9-AF4B-9109A39FC8A1} failed due to the following error: 800aea5f. Exception from HRESULT: 0x800AEA5F.
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.Activator.CreateInstance(Type type)

Troubleshooting Steps Taken:

1. Build Configuration: Ensured the application is built with the x86 target platform to match the COM object’s architecture.
2. DLL Registration: Registered the COM DLL in c:\windows\syswow64 using regsvr32.
3. COM+ Application: Created a new COM+ application on the server, granted the necessary permissions, and imported the COM object as both a **library application and a server application to test different configurations.

Despite these steps, the issue persists on the server.

Possible Cause:

I suspect the issue may be related to the server not recognizing the application as a 32-bit process and, consequently, failing to access the correct 32-bit registry entries or COM environment. However, I am uncertain of how to explicitly force the server to handle this as a 32-bit application and ensure it accesses the 32-bit registry keys.

Could you provide any insights or suggestions on how to resolve this? Specifically, I’d appreciate guidance on:

• Forcing the server to treat this as a 32-bit application (perhaps by modifying IIS or other settings if relevant).
• Ensuring the COM object is accessed from the correct registry path or any other potential configurations I might have missed.

Thank you for your assistance.

I’ve developed a server application using C# that integrates with a COM object provided by an external source. Here's a high-level overview of the application and the issue I’m encountering:

The application creates an instance of the COM object using Activator.CreateInstance. The COM DLL was supplied by an external vendor, and I am incorporating it into my service application to interact with the database. Specifically, the application uses the methods provided by the COM interface to insert data into the database.

Problem: When I run the application in debug mode within Visual Studio on my local machine, everything works as expected, and the COM object is instantiated without any issues. However, after building the application in release mode and deploying it to the server, I receive the following exception when attempting to create the instance of the COM object:

COM error initializing (HRESULT: -2146768289):
Retrieving the COM class factory for component with CLSID {F6A3408C-5652-45A9-AF4B-9109A39FC8A1} failed due to the following error: 800aea5f. Exception from HRESULT: 0x800AEA5F.
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.Activator.CreateInstance(Type type)

Troubleshooting Steps Taken:

1. Build Configuration: Ensured the application is built with the x86 target platform to match the COM object’s architecture.
2. DLL Registration: Registered the COM DLL in c:\windows\syswow64 using regsvr32.
3. COM+ Application: Created a new COM+ application on the server, granted the necessary permissions, and imported the COM object as both a **library application and a server application to test different configurations.

Despite these steps, the issue persists on the server.

Possible Cause:

I suspect the issue may be related to the server not recognizing the application as a 32-bit process and, consequently, failing to access the correct 32-bit registry entries or COM environment. However, I am uncertain of how to explicitly force the server to handle this as a 32-bit application and ensure it accesses the 32-bit registry keys.

Could you provide any insights or suggestions on how to resolve this? Specifically, I’d appreciate guidance on:

• Forcing the server to treat this as a 32-bit application (perhaps by modifying IIS or other settings if relevant).
• Ensuring the COM object is accessed from the correct registry path or any other potential configurations I might have missed.

Thank you for your assistance.

• c#

• Have you registered the com dll on the server as per suggestion #2? – ΩmegaMan Commented Mar 20 at 21:07
• Yep, i have many times. – Newborn Commented Mar 21 at 9:53
• If it works on you dev machine, it's a dependency/deployment issue but the error is weird/unknown. One common issue is missing MSVCRT runtimes on the target PC (make sure they're installed learn.microsoft/en-us/cpp/windows/…) – Simon Mourier Commented Mar 21 at 19:30

1 Answer 1

Ouch. That's going to be fun to debug. Procmon is your best friend in this circumstance and will let you identify whether it is locating the class registration, app, files, etc.... Run it on your local environment and compare to the results of running on the server. At some point you will find a difference.

The other scattered references for HRESULT 0x800AEA5F suggest permissions issues, but it doesn't seem to be a standard HRESULT - so who knows if those are related.

You can configure that your app runs as x86 by setting the "Platform Target" in build properties to x86. You can check whether an assembly is compiled for 32-bit by examining the PE and assembly headers. Make sure to configure the AppPool if you are running under IIS.

Note that regsvr32 is conventional for installation of COM servers, but there is no mandate for a server to support regsvr32 installation. Other dependencies (e.g.: MSVCR runtimes, or other SDK's), and other installation steps may be required.