Call to native DLL fails from a .NET Windows servi

Question

I have a 3rd party API in the form of a native dll that I call from C# using DllImport. This native dll depends on the 3rd party application being open.

When I run the code normally the API does what is expected and drives the application. However, when I run the same code as a Windows service, even as myself, the API returns the same (undocumented) error code that I have seen when the application is closed; process explorer confirms that the native dll is correctly loaded from the application directory.

What could be causing this and how might I be able to resolve the issue?

Answer 1

A bit old, but it came up as one of the top results in a search. So I asume my data would still be helpfull.

I have a 3rd party API in the form of a native dll that I call from C# using DllImport. This native dll depends on the 3rd party application being open.

The (t)rusty Office Interop DLL is the same way. You are actually starting a background instance of the Office Programm in question. The Background Instance needs an interactive Session, even if it does not show anything (design asumptions/mistakes at work). Services do not run in an interactive session since Vista. Using the override is not recommended practice. That is one of the (3?) reasons to not use Office Interop anymore.

Possible workarounds:

1. stop using a service. The Windows Task sheduler can do jsut about the same work, while giving you full interactive sessions. Even MS themself started to move stuff out of services, into the Sheduler whereever possible
2. move the DLL access into a Helper process. That one can run in an interactive session. Use any way of interprocess communication to talk between the helper and the main service. This pattern is primarily used to work with x32 only dll from a x64 programm, but it should work here too. Both the manifest and Process.Start() have a way to start a programm interactively from a Service.

Based on one of the comments it appears you choose option 2, but using a Webservice instead. Unfortunately Webserices/Webapplications are usually run as Windows Service. And that is before you consider that they run under some of the most restrictive rights (since they are web reachable). So it would just get you back to square 1 or even another step backwards to square 0.

Answer 2

Hard to tell, but there is three possibilities I can think of:

• Your service has UI component that require "interact with desktop" option checked
• The working directory for windows service is %WinDir%\system32 (e.g. C:\windows\system32) and your dll have code that uses relative path reference to other resources that can't be found
• Your service uses netpipe communication with the application that run in two different sessions