Windows服务dll搜索路径
我使用 .net 开发了一个 Windows 服务。我的服务对非托管代码进行一些调用，如下所示 -
[DllImport("cmxConnect.dll")]
private unsafe static extern String cmxQuery([MarshalAs(UnmanagedType.LPStr)] String s, long* connPointer);
我已将 cmxConnect.dll 放置在与服务可执行文件相同的文件夹中。如果我将登录用户设置为我的域帐户，则服务可以正常启动。但是，如果我使用本地系统帐户启动服务，则会出现 DLL 未找到异常。我猜测我的环境设置中有一些东西可以让 Windows 找到 cmxConnect.dll。有人能指出这到底是什么吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
据我了解，DllImport 属性只是包装了对 LoadLibrary 的调用，因此标准 动态链接库搜索顺序应适用。
服务将在一个比用户代码更受限制的环境中运行 - 我可以看到，从 exe 文件夹和 System32 之外的任何位置加载 dll 都是不可取的 - 其他任何地方都会导致预加载攻击，这会对服务相当认真。
事情可能就这么简单：服务只能搜索 System32 中的 dll？
查找 dll 的可信位置是：
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:
我在这里猜测，但是你检查过环境变量吗？您的本地系统 a/c 是否具有相同的 Env 集。瓦尔斯？
I'm guessing here, but have you checked the Environment Variables. Does your local system a/c have the same set of Env. Vars?
尝试使用 msft 的进程监视器。该工具将向您显示该服务正在哪里寻找您的 dll。它甚至可能正在寻找依赖的 dll。这也会显示在进程监视器中。
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.
本地系统帐户非常强大。为了安全起见，可能会为此帐户禁用 DLL 搜索顺序。 （如果它仅按名称进行搜索，并且有人设法将恶意 DLL 放入搜索顺序中的某个位置，那么您就遇到了权限升级漏洞。）如果它是 .NET 服务，您可能希望将 DLL 添加到您的清单并将 DLL 安装在 GAC 中。 （我不是 .NET 人。我之前刚刚听说过这些术语。）
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.)