Windows service dll search path.

Question

I have developed a windows service using .net . My service makes some calls to unmanaged code like follows -

[DllImport("cmxConnect.dll")]
private unsafe static extern String cmxQuery([MarshalAs(UnmanagedType.LPStr)] String s, long* connPointer);

I have placed cmxConnect.dll within the same folder as the service executable. The service starts fine if I set the logon user to be my domain account. But if I start the service using the local system account I get DLL not found exceptions. I am guessing there is something in my environment settings thats enables windows to find cmxConnect.dll. Can someone point out what exactly this is?

Answer 1

I'm guessing here, but have you checked the Environment Variables. Does your local system a/c have the same set of Env. Vars?

Answer 2

The Local System account is pretty powerful. It's possible that the DLL search order is disabled for this account for security. (If it goes searching just by name, and somebody manages to put a malicious DLL somewhere in the search order, then you've got an escalation of privilege vulnerability.) If it's a .NET service, you probably want to add your DLL to your manifest and get your DLL installed in the GAC. (I'm not a .NET guy. I've just heard these terms before.)

Answer 3

As I understand things the DllImport attribute simply wraps a call to LoadLibrary, so the standard Dynamic Link Library Search Order should apply.

Services will run in a far more restricted environment that user code - I can see that it would be undesirable to load dlls from any location other than the exe's folder and System32 - everywhere else opens one up to a pre-loading attack, and that would be pretty serious with a service.

It could be that simple: Services can only search for dlls from System32?

The trusted locations to find dlls are:

1. When passed an explicit path its clear to LoadLibrary that the app knows which dll it wants. Can you pass a fully qualified path to DllImport?
2. The most trusted non-fully qualified place to search for dlls is in WinSxS - if you build the dll yourself, perhaps deploying it as a native Side by side assembly is an option.
3. The exe's own folder. Usually. I can't imagine that because the service is a .net app that this wouldn't apply. But clearly there is an issue here.
4. System32 - you might need to install it here.

Answer 4

Try process monitor from msft. This tool will show you where the service is looking for your dll. It may even be looking for a dependant dll. This would also show up in process monitor.