1

We have a WCF service hosted in IIS that currently calls a VB6 DLL to do part of its job. This works fine, but we can't deploy the service to a 64-bit target environment without configuring IIS to run it in a 32-bit worker process.

I am currently investigating ways around that restriction. Porting the VB6 DLL to .NET is not possible for various reasons, so I created an ActiveX EXE wrapper around the DLL in VB6, so that the service can run in 64-bit and the VB6 parts in 32-bit.

When I tested the service I got this error:

Type: System.UnauthorizedAccessException
Message: Retrieving the COM class factory for component with CLSID {9AE7303B-D159-43F6-B1A5-52D297581820} failed due to the following error: 80070005.

After some Googling I found that this is due to either:

  1. Calling an MS Office component
  2. DCOM permissions not being configured
  3. NTFS file permissions not allowing read/exec access to the IIS worker process identity (ASPNET in my environment)

Of these:

  1. Definitely not applicable
  2. Also not applicable; I am not hosting the EXE in DCOM or COM+, just a simple COM out-of-process activation
  3. This looks likely; however, I checked the permissions, and NTFS reports that the Users group (which ASPNET is a member of) does indeed have read/exec access to the file

I tried calling the EXE from a unit test fixture, which is executed in my admin-level account rather than the IIS worker process account, and it worked fine, so the error is definitely something to do with permissions. I'm not sure what to do next. Can anyone suggest things I can check?

My test environment is Windows XP / IIS 5.1

UPDATE:

The IIS virtual directory is configured for Anonymous+Windows access; the WCF service uses only Anonymous authentication, the Windows authentication is for the VS debugger. Task Manager reports that the aspnet_wp.exe process is definitely running in the ASPNET account.

I explicitly granted Read and Execute access to the ASPNET and IUSR_<machine> accounts on all the COM exes and dlls involved. This made no difference.

I explicitly granted Local Launch and Local Activation access to the ASPNET and IUSR_<machine> accounts on the relevant interfaces in the DCOM configuration. This made no difference either.

As I see it I have 3 options:

  • Keep trying to get this working somehow.
  • Go the whole hog and host the EXE in COM+.
  • Give up. Tell users that the WCF service must be configured to run in a 32-bit app pool on 64-bit Windows.
Christian Hayter
  • 30,581
  • 6
  • 72
  • 99
  • 2
    Let IIS run it in a 32bit app pool, you're opening yourself up to a whole world of hurt trying to work around this. My two cents. – Binary Worrier Jun 01 '11 at 16:32
  • Try giving your IUSR_computername (Internet guest account), account access to your exe. – jac Jun 01 '11 at 16:48
  • @Binary: Do you mean (a) trying to avoid COM+ is a bad idea, or (b) any kind of 64-32 bit COM interop is a bad idea regardless of how it's hosted? – Christian Hayter Jun 02 '11 at 13:59
  • @Beaner: Thanks for the suggestion, see my latest updates – Christian Hayter Jun 02 '11 at 14:01
  • @Christian: Mixing 64 & 32 bit COM (or COM+) interop is a bad idea. Have you a requirement that the Service should run as a 64 bit app? Or is it simply that it's on a 64bat machine and you'd like it to have the extra reach? – Binary Worrier Jun 02 '11 at 14:34
  • @Binary: No requirement, just that if we can get 64-bit "for free", we might as well support it. – Christian Hayter Jun 02 '11 at 14:59
  • @Binary: Could you give me any details or links on why 64-32 bit COM interop is bad, please? I'm keen to avoid mistakes that others have made, but so far I can't find anything on Google that describes any problems with it. – Christian Hayter Jun 03 '11 at 07:46
  • For why the 64bit app can't load the 32bit dll see MSDN article [Process Interoperability](http://msdn.microsoft.com/en-us/library/aa384231(VS.85).aspx). For and a **very slow** way to get around the restriction [see this answer](http://stackoverflow.com/questions/359331/access-x86-com-from-x64-net/359389#359389). Hope these help :) – Binary Worrier Jun 03 '11 at 08:02
  • So your main concerns are: the performance hit of the cross-process marshalling, and the hassle of configuring a suitable host? These are very valid concerns and I'm not talking them down, I just wanted to make sure that you didn't know of any bugs or other problems with this kind of interop. – Christian Hayter Jun 03 '11 at 08:43

1 Answers1

2

Your error is an Unauthorized access exception. Therefore, the problem is probably rights related.

You could check what the security context of the 32bit worker process is.

Also check your event log, they may be information there about what account is being used.

Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252