LoadLibraryW返回nullptr，GetLastError（）返回3221225619

Question

描述我遇到的问题会花费太长时间，但问题的尖锐是：

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

2. 进程监视器不会记录任何可疑的失败，或者实际上与加载dll成功时有什么不同（可以在另一个上下文中）。

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

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

假设3221225619不是有效的错误代码，那么Windows甚至没有错误代码可能会出错：

修改

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

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

Answer 1

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

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

我要感谢@WhozCraig，@ DanielDaranas和其他所有发表有益评论的人。对于阅读此内容的其他人，有一篇关于HRESULT的文章在维基百科上展开了他们的观点：http://en.wikipedia.org/wiki/HRESULT。

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

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