InteropServices COMException when executing a .net app from a web CGI script on Windows Server 2003

Question

Disclaimer: I'm completely clueless about .net and COM.

I have a vendor's application that appears to be written in .net and I'm trying to wrap it with a web form (a cgi-bin Perl script) so I can eventually launch this vendor's app from a separate computer. I'm on a Windows Server 2003 R2 SE SP1 system and I'm using Apache 2.2 for the web server and ActivePerl 5.10.0.1004 for the cgi script. My cgi script calls the vendor's app that resides on the same machine using the Perl backtick operator.

...
$result = "Result: " . `$vendorsPath/$vendorsExecutable $arg1 $arg2`;
...

Right now I'm just running IE web browser locally on the server machine and accessing "http://localhost/cgi-bin/myPerlScript.pl". The vendor's app fails and logs a debug message that includes the following stack trace (I changed a couple names so as to not give away the vendor's identity):

...
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80043A1D): 0x80040154 - Class not registered
   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
   at VendorsTool.Engine.Core.VendorsEngine.LoadVendorsServices(String fileName, String& projectCommPath)
...

When I run the vendors app from the Windows command line on the server machine with the exact same arguments that the cgi script is passing it runs just fine, so there's something about invoking their app via the web script that is causing a problem. This problem is likely security related because the whole thing runs just fine on a Windows XP Pro machine (both command line and web invocation). I actually developed my web script there and got it completely working there before I tried moving it to the Windows Server 2003 machine. So what's different about the Windows Server 2003 machine that would keep the vendor's .net app from being executed successfully by a web cgi script?

Can I fix this problem somehow to make it work on my server or will the vendor have to make a change to their .net app and ship out a new version? I'm probably the only person in the world who is trying to execute this vendor's app from a separate program, so I hate to bother the vendor with the issue if there's a workaround that I can implement myself here on my server machine. Plus, I'm in kind of a hurry and I don't want to wait 4 or 6 months for the vendor to put in a fix and deploy a new version.

Thanks for any advise you can give.

Answer 1

The typical cause would be that you did not install a prerequisite. It's hard to say which, because COM classes are used by so many applications.

One way to find out the missing class is the sysinternals tool process monitor. It can be used to montior registry usage. This helps you track exactly what class the script is trying to load. Named COM classes reside under

HKEY_LOCAL_MACHINE\SOFTWARE\Classes

and their underlying GUID entry is in

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID

If Apache is looking for an entry there but doesn't find it, that might be the COM class the perl script is missing.

Answer 2

It seems to me that you have permission problem. It looks like your .NET application try to use a COM object and it has not enough permission to do this.

Every COM object (COM server) has launch/activation and access permission (just start dcomcnfg and look at DCOM configuration of some well known Applications). With respect of dcomcnfg (Component Services) you can not only see but also change this permissions (select an application and open properties dialog in the context menu. Then choose "Security" tab, choose Customize in the "Launch and Activation Permission" block and then click "Edit"). Typical problem is that INTERACTIVE users have launch/activation permission to the most COM objects, but processes running as service are not a member of this group. So you have to customize permission by granting for an some account (used by your Apache web server) or a group (like a IIS_IUSRS) the same launch permission which has INTERACTIVE users. This permission information will be saved in a subkey of the HKEY_CLASSES_ROOT\AppID key (see binary AccessPermission registry value).

To identify the COM object which makes problem I'll recommend you Process Monitor (see http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and Process Explorer (see http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx). Process Monitor can helps you to find out exactly which other processes your program ($vendorsExecutable) try to start. One from the last accesses to HKEY_CLASSES_ROOT are used to start a COM object. You will find out which process it is. Don't forget to start this tools under an account with full administrative rights (on a server such problem typically not exist). To find the information which you need more quickly use filter to a process name and searching features of Process Monitor.

If you do such work at the first time it can look very complex. It is not easy, but everything have well defined logic and I am sure, that you solve this problem.

Answer 3

Please tell me if this helps: You receive a "0x80040154 (Class not registered)" error message when you register an ATL server

Depending on which tools the vendor has developed his application, it might be caused because of a DLL registration, which is actually not registered on your Windows Server 2003.