0

描述我遇到的问题需要太长时间，但最尖锐的问题是：

  1. 给定有效路径时，LoadLibraryW 失败（返回 nullptr）。

  2. Process Monitor 没有记录任何可疑的故障，或者确实与它成功加载 dll 时的任何不同（它可以在另一个上下文中）。

  3. dll 没有非系统依赖项。

  4. ...最糟糕的是，GetLastError 返回的 Windows 错误代码是 3221225619。

假设 3221225619 不是有效的错误代码，那么会出现什么问题以至于 Windows 甚至没有错误代码呢？

编辑：

我认为有些人想要更多关于失败本身的细节：

  • 它似乎不是输入 - 它在工作和失败版本中是相同的，并且当输入字符串被破坏时，LoadLibraryW 已成功声明“文件不存在”。当前输入已硬编码，几乎没有出错的余地。
  • dll在Release中编译，调用代码在Debug中。我已经这样做了 18 个月没有问题，但你永远不知道。
  • Process Monitor 包报告了大约 30 个在 LoadLibraryW 中运行的内部操作，包括 CreateFile、LoadImage、RegOpenKey。这些对于工作调用和失败调用是相同的，具体到文件大小和内存位置。
  • 在调用它的 C++ 对象中没有明显的内存损坏，正如我所说，Process Monitor 在两种情况下都提供相同的基本映像地址。
  • 失败是 100% 一致的——每次都是同一时间，同一地点。
4

1 回答 1

0

抱歉，这不是一个完全正确的答案，但问题已经解决。

首先，我在这里注意到了一个类似的问题：C++ Loadlibrary() error 3765269347。我认为这个提供了更多细节，如果你和我处于相似的位置，值得一看。

感谢@WhozCraig、@DanielDaranas 和其他所有提出有用意见的人。对于阅读本文的其他人，有一篇关于 HRESULT 的好文章扩展了他们在 Wikipedia 上的观点： http ://en.wikipedia.org/wiki/HRESULT 。

就我而言，这个问题就像它出现时一样神秘地消失了。我创建了一个 C++ 类来定期调用 dll。我最初的努力在第一次调用之前立即加载了 dll，并将其缓存在内存中。这在原则上与一年多的工作方式相同。这导致了上面的神秘错误。

我已经对其进行了重构以在构建期间加载 dll，但仅在运行时从中提取函数。这显然有效，并且可能是一种更好的方法（在构建期间加载 dll，在销毁期间释放它）。由于在构造和第一次调用 dll 之间几乎没有发生什么，我不明白为什么一种方法会产生操作系统错误，而另一种不会。

于 2013-11-08T10:40:27.243 回答