Exception: Retrieving the COM class factory for component with CLSID {}

[Frinavale]

Hi guys,

I've created a VB.Net project and have compiled it, run it, tested it on a machine that has a 32bit processor. I am now trying to move this project onto a 64bit processor server that is running IIS6.

The project works wonderfully until it tries to access a DLL that is essential to the project. At that time I am getting the following error:

Exception: Retrieving the COM class factory for component with CLSID{...}

I have registered the DLL on the server.

After searching the web I've found to possible causes to the error but I don't know how to get around them.

The first possible cause is that the ASPNET user doesn't have the privialges to access this dll. I have no idea how to set the permissions for a registered dll.

The second is that the 64bit environment will not run my 32bit DLL. Is there a way around this problem?

Thanks in advance!
-Frinny

[Motoma]

Hi guys,

I've created a VB.Net project and have compiled it, run it, tested it on a machine that has a 32bit processor. I am now trying to move this project onto a 64bit processor server that is running IIS6.

The project works wonderfully until it tries to access a DLL that is essential to the project. At that time I am getting the following error:

Exception: Retrieving the COM class factory for component with CLSID{...}

I have registered the DLL on the server.

After searching the web I've found to possible causes to the error but I don't know how to get around them.

The first possible cause is that the ASPNET user doesn't have the privialges to access this dll. I have no idea how to set the permissions for a registered dll.

The second is that the 64bit environment will not run my 32bit DLL. Is there a way around this problem?

Thanks in advance!
-Frinny

I ran into a similar problem once, and the error was solved by simply including the DLL in the references.

In the (very) unlikely case that the 64bit environment cannot load the 32bit DLL, Visual Studio has an option to specify the target architecture. I have never run into a circumstance where this is needed, however.

Is this a COM DLL or a .NET DLL? You may need to open up the Component Services and adjust permissions and execution security there.

Sorry, I'm not connected to our network right now, so I can't give more elaborate instructions, hopefully someone else catches where I am going and can provide the exact names, paths, and tabs you need to click :P

[Frinavale]

I ran into a similar problem once, and the error was solved by simply including the DLL in the references.

In the (very) unlikely case that the 64bit environment cannot load the 32bit DLL, Visual Studio has an option to specify the target architecture. I have never run into a circumstance where this is needed, however.

Is this a COM DLL or a .NET DLL? You may need to open up the Component Services and adjust permissions and execution security there.

Sorry, I'm not connected to our network right now, so I can't give more elaborate instructions, hopefully someone else catches where I am going and can provide the exact names, paths, and tabs you need to click :P

By including the DLL in the references, do you mean in the project itself?
The reference has already been included in the project and the project has been compiled on the 32bit machine with this DLL referenced.

It is a COM DLL. I'm not sure what a Component Service. I'll try looking this up.

Thanks for your help!

-Frinny

[Frinavale]

By including the DLL in the references, do you mean in the project itself?
The reference has already been included in the project and the project has been compiled on the 32bit machine with this DLL referenced.

It is a COM DLL. I'm not sure what a Component Service. I'll try looking this up.

Thanks for your help!

-Frinny

Ok I'm an idiot sometimes. I don't know why I said I didn't know what a Component Service was...I guess I was just having one of those brain blocks...its that utility in Windows that I've only used a couple of times in my life so far.

I tried to use the Component Service to set the permissions on my DLL yesterday but my DLL isn't listed there. Do you know how to make it show up?

I've looked for it in both the COM+ Applications, and the DCOM Config...could it possibly be somewhere else?

I also tried going directly into the registration and setting the permissions directly on the DLL. This didn't help.

Sorry for the temporary idiocy (at least I hope it was temporary hehe)

-Frinny

[Motoma]

Ok I'm an idiot sometimes. I don't know why I said I didn't know what a Component Service was...I guess I was just having one of those brain blocks...its that utility in Windows that I've only used a couple of times in my life so far.

I tried to use the Component Service to set the permissions on my DLL yesterday but my DLL isn't listed there. Do you know how to make it show up?

I've looked for it in both the COM+ Applications, and the DCOM Config...could it possibly be somewhere else?

I also tried going directly into the registration and setting the permissions directly on the DLL. This didn't help.

Sorry for the temporary idiocy (at least I hope it was temporary hehe)

-Frinny

The way I usually do it, is open Component Servies > My Computer > COM+ Applications, then right click on COM+ Applications and go New > Applicaiton.
Do an Empty application, type a name, set the options, and hit finish.
Select the application under the COM+ Applications from the left pane, and then select Components. Then drag and drop the DLL there. Now you will be able to fool with the properties of your DLL.
I'm sure there are other (better) ways of doing it, but I don't know of those ways.

[Frinavale]

Hi there!

I still haven't solved this problem yet but at least now I have a good idea of what is wrong.

I guess I should have mentioned in my first post that the project is a .NET web application that uses a COM DLL as a reference to do some important processing.

Anyways, using Depends.exe (that comes with Visual Studio) I was able to determine that the DLL has some components missing but also (more importantly) that it has been compiled for a 32bit OS.

Since the OS I'm moving the application to is 64bit there are conflicts. I think that if I am able to compile the web-application targeting a 64bit platform I'll be able to solve my problem (hopefully!).

All of my attempts at registering the DLL in the SysWOW64 were in vein because when I deploy the web application from my 32bit machine it moves the whole assembly over and uses its own personal DLLs located in its "bin" folder. It never even looks to see what is installed on the server.

My question now is, how do I compile the web-application targeting the 64bit platform?

I've been trying to find the answer online but every time I think I've found help they step me through menus that don't exist.

Does anyone know how to do this?

Thanks a lot for your help

-Frinny

[Motoma]

Hi there!

I still haven't solved this problem yet but at least now I have a good idea of what is wrong.

I guess I should have mentioned in my first post that the project is a .NET web application that uses a COM DLL as a reference to do some important processing.

Anyways, using Depends.exe (that comes with Visual Studio) I was able to determine that the DLL has some components missing but also (more importantly) that it has been compiled for a 32bit OS.

Since the OS I'm moving the application to is 64bit there are conflicts. I think that if I am able to compile the web-application targeting a 64bit platform I'll be able to solve my problem (hopefully!).

All of my attempts at registering the DLL in the SysWOW64 were in vein because when I deploy the web application from my 32bit machine it moves the whole assembly over and uses its own personal DLLs located in its "bin" folder. It never even looks to see what is installed on the server.

My question now is, how do I compile the web-application targeting the 64bit platform?

I've been trying to find the answer online but every time I think I've found help they step me through menus that don't exist.

Does anyone know how to do this?

Thanks a lot for your help

-Frinny

Doing this in VB.NET, there are no "target architectures;" everything is build for the .NET framework. If you are certain that the issue is being unable to load the 32 bit DLL, then you will need to recompile the DLL.
What 64 bit architecture is the machines you are having problems with? I know that the x64 supports the x86 instruction set, and have never had an issue with this on my machine. Windows x64 systems are usually able to run all 32 bit applications using the WOW64 subsystem.
I have no idea what support IA64 has for 32 bit systems, but I would assume there is a similar way of handling things there.

[Frinavale]

Doing this in VB.NET, there are no "target architectures;" everything is build for the .NET framework. If you are certain that the issue is being unable to load the 32 bit DLL, then you will need to recompile the DLL.
What 64 bit architecture is the machines you are having problems with? I know that the x64 supports the x86 instruction set, and have never had an issue with this on my machine. Windows x64 systems are usually able to run all 32 bit applications using the WOW64 subsystem.
I have no idea what support IA64 has for 32 bit systems, but I would assume there is a similar way of handling things there.

The server is running Windows Server 2003 Standard x64 Edition with IIS6.
Do I have to put my project into a special folder for it to run using the WOW64 subsystem? I can't really move it off of the IIS....

When I registered the DLL I had to place it into the SysWOW64 in order to do so, but l application is ignoring the registered DLL.

When I load the DLL the web-application is using in the Depends.exe I get the following errors:
" Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has unresolved import due to a missing export function in a delay-load dependent module."

The missing DLL is: DWMAPI.DLL

The COM object that's causing all the problems has been developed using VB6 and I'm not sure that it will be able to be recompiled targeting a 64bit platform.

Thanks so much for your help.
-Frinny

[Motoma]

The server is running Windows Server 2003 Standard x64 Edition with IIS6.
Do I have to put my project into a special folder for it to run using the WOW64 subsystem? I can't really move it off of the IIS....

When I registered the DLL I had to place it into the SysWOW64 in order to do so, but l application is ignoring the registered DLL.

When I load the DLL the web-application is using in the Depends.exe I get the following errors:
" Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has unresolved import due to a missing export function in a delay-load dependent module."

The missing DLL is: DWMAPI.DLL

The COM object that's causing all the problems has been developed using VB6 and I'm not sure that it will be able to be recompiled targeting a 64bit platform.

Thanks so much for your help.
-Frinny

I had not used Depends.exe until just now, however, when I launched it with three DLLs located in it's own directory, I recieved the same messages on two of them:

DWMAPI.DLL: Error Opening File. The system cannot find the file specified (2).
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has unresolved import due to a missing export function in a delay-load dependent module."

This leads me to believe that this is not the source of your problem.

What you could do is create a small test program to load up your DLL and call one of it's functions. In C# you would do this like so:

Using System.Runtime.InteropServices;
 
 
public class myclass
{
    [DllImport("crapapp.dll")] 
    public static extern int intReturningFunctionFromDLL(int arg1, string arg2);
 
    static void main()
    {
        if(intReturningFunctionFromDLL(5, "toasty")) Console.WriteLine("Success");
        else Console.WriteLine("Success as well!");
    }
}
 
 

P.S. My code is guarenteed not to work, it is just meant to be an example/a guide/some crap pseudo code.

[Frinavale]

I had not used Depends.exe until just now, however, when I launched it with three DLLs located in it's own directory, I recieved the same messages on two of them:

This leads me to believe that this is not the source of your problem.

What you could do is create a small test program to load up your DLL and call one of it's functions. In C# you would do this like so:
...

P.S. My code is guarenteed not to work, it is just meant to be an example/a guide/some crap pseudo code.

I created a test windows application which uses the DLL that has been registered on the computer (in the SysWOW64 folder).

It runs fine.

The web-application still does not work despite the fact that I have changed IIS to run 32-bit applications on the 64-bit server.

I found out how to do this at this site. This site mentions that if the 32-bit problems still persist to check to see if the application needs to reference the %windir%\syswow 64\inetsrv to resolve the problem.

I'm sure that I need to do this step because the DLL is working fine in the test windows application.... and the web-application's version is not working.

Does anyone know how to change the application so that it references this directory?

Thanks a lot

-Frinny