A: 

I cannot provide an explanation for the error, only my initial suspicion that there is a permission difference between the context in which your code is run as a service and the context in which it is run when you place it in a console application. The E_HANDLE HRESULT is my clue here. Assuming that you run the console application as your logged-in user, you could try configuring the service to start as that user as well. If it works in that configuration, then you can attempt to narrow down what required resource is unavailable when it fails.

I can suggest a workaround. If there is an oddity of the DLL in question that prevents it from working in a hosted service, you can take the sacrificial process approach, so named because it is typically used to isolate a DLL that crashes often. Briefly, you create a proxy program whose only purpose is to load and call the DLL on behalf of your main process, using named pipes or some other IPC method to pass requests and results. If the DLL crashes, you start a new instance of the proxy program. In your case it would have the added benefit that only the wrapper program would need to be 32-bit.

Matthew Xavier
A: 

Do you see anything special in the Event viewer?.
In Vista if there a manifest problem you will see traces of it in the Event Viewer, it will tell you to use SxsTrace.

Shay Erlichmen
A: 

Could you manually add a manifest to this DLL yourself, using the mt.exe file?

MSDN Article on using mt.exe

Spence
+1  A: 

Microsoft Product Support has resolved this question: It's by design. The unmanaged code is not loaded in the default AppDomain when using WcfSvcHost or the IIS WCF host.

A pure image will use a CLR version of the C run-time library. However, the CRT is not verifiable, so you cannot use the CRT when compiling with /clr:safe. For more information, see C Run-Time Libraries.

http://msdn.microsoft.com/en-us/library/k8d11d4s.aspx

George Tsiokos