loadLibraryw返回nullptr，getlastror（）返回3221225619

Question

描述我一直遇到的问题可能会花费太长时间，但是急剧的问题是：

1. 当给出有效的路径时，LoadLibraryw失败（返回NULLPTR）。

2. 流程监视器记录没有可疑故障，或者实际上与成功加载DLL的任何不同之处（在其他情况下可以）。

3. DLL没有非系统依赖性。

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

假设3221225619不是有效的错误代码，那么Windows甚至没有错误代码的错误是什么？

编辑：

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

• 它似乎不是输入 - 它在工作和失败版本中是相同的，并且当输入字符串被肢解时，LoadLibraryw成功声明了“文件不存在”。当前的输入将其硬编码，几乎没有错误的空间。
• DLL在发行版中编译，并在调试中进行调用代码。我已经这样做了18个月没有问题，但您永远不会知道。
• 流程监视器软件包报告了大约30个内部操作，其中包括createFile，loadImage，repopenkey。这些是 完全相同的 对于工作呼叫和失败的调用，直到文件和内存位置的大小。
• C ++对象中没有明显的内存损坏，正如我所说，Process Monitor在两种情况下都提供了相同的基本图像地址。
• 故障是100％一致的 - 同一时间，每次相同的位置。

Answer 1

抱歉，这不是 确切地 答案，但问题已经解决。

首先，我刚刚注意到一个类似的问题： C ++ loadLibrary（）错误3765269347. 。我认为这给出了更多细节，如果您处于与我的位置相似的情况下，值得一看。

感谢@Whozcraig，@danieldaranas和其他所有发表评论的人。对于其他阅读本文的人来说，关于Hresult的一篇很好的文章，可以扩展其关于Wikipedia的观点： http://en.wikipedia.org/wiki/hresult.

就我而言，这个问题已经与出现的神秘消失了。我创建了一个C ++类，以定期调用DLL。我最初的努力在第一次通话之前立即加载了DLL，并将其缓存在内存中。原则上，这与它的运作一年多。这导致了上面的神秘错误。

我已经对其进行了重构以在施工过程中加载DLL，但仅在运行时从中提取功能。这显然有效，并且可能是一种更好的方法（在施工过程中加载DLL，在破坏过程中释放它）。由于构造和对DLL的第一个呼叫之间的发生很少，我看不出为什么一种方法应该产生OS错误，而另一种方法则不会。