在调试和发布两种模式下编译我的代码是成功的。调试模式执行并正常工作，但是当我执行发布模式时，它说“应用程序无法正确启动0x80000003”。
这是什么错误以及为什么调试模式工作正常但不释放。 用于调试和释放的DLL存在于相同的目录名“bin”中。两种模式的“lib”也放在同一目录中。
我试图以多种方式解决但未成功？指导我如何解决这个问题？感谢。
答案 0 :(得分：0)
为什么调试模式工作正常但没有发布
可能有很多原因导致一个构建工作，而另一个构建不工作。数据结构的形状和大小可能因#ifdef而不同，或者因为编译器发出不同的代码，正在执行的代码可能不同 - 再次因为#ifdef之类的结构或编译器的代码正在发光。
当你的代码中包含一个bug时，这很重要。假设您有一个错误计算数组长度（或结构大小或其他大小）的错误。你做一些指针运算并使用该指针将一些数据写入内存 - 只有你写错了地方。这个错误是否会破坏您的程序可能取决于您覆盖的内存中的内容。
如果您很幸运，您的程序几乎立即崩溃，因为您覆盖的内容对于您的错误后立即执行的某些代码非常重要。如果你只是有点幸运，你的程序会在一段时间后在程序的完全不同的部分崩溃，因为你覆盖的内容对于远离你的bug的代码很重要。如果你真的不走运，你的程序根本不会崩溃，直到几年之后，一个完全不相关的变化会在内存中移动，所以现在你忽略了 重要的。
有时称为Heisenbugs
的原因还有很多其他原因这是什么错误
查找0x80000003等错误的地方是WinError.h文件，您可以在使用的SDK中找到该文件（Visual Studio 2010附带的文件或稍后安装的文件）。查看WinError.h，您会发现E_INVALIDARG被定义为_HRESULT_TYPEDEF_(0x80000003L)。
这并不一定有帮助，因为我们不知道返回该错误的原因是什么，或者为什么它返回该错误，甚至你的0x80000003实际上是E_INVALIDARG - 它可能是一些其他的错误相同的值，或某些代码错误使用E_INVALIDARG或其他内容。
另一种可能性是0x80000003被抛出hard-coded breakpoint exception - 很可能是因为你的程序已经达到了“这应该永远不会发生”的地方之一，唯一有意义的就是抛出异常并崩溃。如果你查看NtStatus.h（在你找到WinError.h的同一个地方），你会发现STATUS_BREAKPOINT被定义为((NTSTATUS)0x80000003L)
如何解决这个问题
诀窍是弄清楚导致0x800000003的原因（以及代码中的位置），这样你就可以缩小它发生的原因。最有可能是一个例外，但为什么要妄下结论呢？
您可以在调试器内运行发布版本，就像运行调试版本一样 - 即使用Release目标构建代码，然后按F5或Debug |开始调试。查看输出窗口，您可能会看到一些有助于您解释错误的信息。
您也可以使用Debug |用于添加值为80000003的新Win32 Exception的异常菜单，并将其设置为在抛出时中断，而不是在未处理时中断。这样你就应该在抛出异常时停止在调试器中（如果它实际上被抛出）。
当然可能即使在调试器中运行程序也足以改变事情，因此不会发生问题。