2010-09-08 33 views
2

我开发了一个使用.net的Windows服务。我的服务对非托管代码调用一些像如下 -Windows服务DLL搜索路径

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

我都放在同一个文件夹作为服务可执行文件中cmxConnect.dll。如果我将登录用户设置为我的域帐户,服务就会正常启动。但是,如果我使用本地系统帐户启动服务,则会出现DLL未找到异常。我猜测我的环境设置中有一些东西让Windows能够找到cmxConnect.dll。有人能指出这到底是什么吗?

回答

0

本地系统帐户非常强大。为了安全起见,可能会为此帐户禁用DLL搜索顺序。 (如果它只是按名称搜索,并且有人设法在搜索顺序中放置一个恶意DLL,那么你的权限漏洞就会升级)。如果它是一个.NET服务,那么你可能想要将DLL添加到您的清单并将您的DLL安装在GAC中。 (我不是.NET的人,我刚刚听过这些条款。)

+1

我想出问题不在于我指的是dll,而是由该dll引用的其他dll。 Windows无法找到其他DLL并输出一个错误的错误消息,它无法找到cmxConnect.dll – user434541 2010-11-08 01:27:29

0

我在这里猜测,但你有检查环境变量。您的本地系统a/c是否具有相同的Env组。瓦尔?

0

据我所知,DllImport属性只是简单地调用LoadLibrary,所以标准Dynamic Link Library Search Order应该适用。

服务将运行在一个更受限制的用户代码环境中 - 我可以看到,从exe文件夹和System32以外的任何位置加载dll是不可取的 - 在其他地方打开一个直到预加载攻击,这对服务来说会非常严重。

它可能很简单:服务只能从System32搜索dll?

受信任的位置找到的DLL:

  1. 当通过该应用程序知道哪些dll它想要一个明确的路径其明确给LoadLibrary。你能否将完全合格的路径传递给DllImport?
  2. 最值得信任的非完全合格的搜索dll的地方是在WinSxS中 - 如果您自己构建dll,可能将其部署为本地并排组装是一种选择。
  3. 该exe文件夹。通常。我无法想象,因为该服务是一个.net应用程序,这不适用。但显然这里有一个问题。
  4. System32 - 您可能需要在此处安装它。
1

从msft尝试进程监视器。这个工具会告诉你服务在哪里寻找你的dll。它甚至可能正在寻找一个相关的DLL。这也会显示在进程监视器中。

+1

我该如何启动进程监视器? – 2014-07-22 09:34:58