Windows 服务 dll 搜索路径
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3670496/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Windows service dll search path
提问by user434541
I have developed a windows service using .net . My service makes some calls to unmanaged code like follows -
我已经使用 .net 开发了一个 Windows 服务。我的服务对非托管代码进行了一些调用，如下所示 -
[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?
我已将 cmxConnect.dll 放在与服务可执行文件相同的文件夹中。如果我将登录用户设置为我的域帐户，该服务将正常启动。但是，如果我使用本地系统帐户启动服务，则会出现 DLL not found 异常。我猜我的环境设置中有一些东西可以让 Windows 找到 cmxConnect.dll。有人能指出这究竟是什么吗？
采纳答案by Adrian McCarthy
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.)
本地系统帐户非常强大。出于安全考虑，可能为此帐户禁用了 DLL 搜索顺序。（如果它仅按名称搜索，并且有人设法将恶意 DLL 放在搜索顺序中的某个位置，那么您就有了特权漏洞升级。）如果它是 .NET 服务，您可能希望将您的 DLL 添加到您的清单并将您的 DLL 安装在 GAC 中。（我不是 .NET 人。我之前才听说过这些术语。）
回答by Mike
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.
从 msft 尝试进程监视器。此工具将向您显示该服务正在寻找您的 dll 的位置。它甚至可能正在寻找依赖的 dll。这也将显示在进程监视器中。
回答by Chris Becke
As I understand things the DllImport attribute simply wraps a call to LoadLibrary, so the standard Dynamic Link Library Search Ordershould apply.
据我了解，DllImport 属性只是包装了对 LoadLibrary 的调用，因此应该应用标准的动态链接库搜索顺序。
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.
服务将在比用户代码更受限制的环境中运行 - 我可以看到从 exe 的文件夹和 System32 以外的任何位置加载 dll 都是不可取的 - 其他任何地方都会打开一个预加载攻击，这将对服务非常认真。
It could be that simple: Services can only search for dlls from System32?
可能就是这么简单：服务只能从 System32 中搜索 dll？
The trusted locations to find dlls are:
查找 dll 的可信位置是：
- 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?
- 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.
- 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.
- System32 - you might need to install it here.
- 当向 LoadLibrary 传递显式路径时，应用程序知道它想要哪个 dll。您可以将完全限定的路径传递给 DllImport 吗？
- 搜索 dll 的最值得信赖的非完全限定位置是在 WinSxS 中 - 如果您自己构建 dll，也许可以选择将其部署为本机并行程序集。
- exe 自己的文件夹。通常。我无法想象，因为该服务是一个不适用的 .net 应用程序。但显然这里有问题。
- System32 - 您可能需要在此处安装它。
回答by Sidharth Panwar
I'm guessing here, but have you checked the Environment Variables. Does your local system a/c have the same set of Env. Vars?
我在这里猜测，但是您是否检查过环境变量。您的本地系统 a/c 是否具有相同的 Env. 瓦尔斯？
