Visual Studio 发布版本
我正在尝试为我编写的 C++ 应用程序生成发布版本。 当您从 VS2008 中运行该应用程序时，该应用程序运行良好（调试和发布）； 但是当您运行可执行文件时，它几乎每次都会崩溃。
现在，是否有一种破解方法可以使我可以将此应用程序作为独立应用程序运行，而不必运行所有代码并找到导致它的错误？
提前致谢。
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
简而言之，不。
你必须找到这个错误，如果它在VS中工作，那么我会冒险猜测这是一个计时问题，可能你正在覆盖共享线程数据，这在内部不太可能（尽管仍然可能看到） VS 因为它在调试环境中运行，这会减慢它的速度。
如果您需要帮助查找错误，请告诉我们更多信息。 否则，使用调试符号 (pdb) 构建您的版本，安装 DrWatson 作为系统调试器并独立运行。 当它崩溃时，DrWatson 将创建一个小型转储文件，将其加载到 WinDbg（我最喜欢的）中，您将能够准确地看到错误所在（它甚至会告诉您转储包含异常并默认显示它） 。您需要在 WinDbg 中添加源代码路径和符号路径才能正确执行此操作）。
然后您还将知道如何在应用程序现场运行时诊断崩溃。
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
您正在加载外部资源吗？ 如果您检查 C++ 程序中的相对路径是否正确。
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
一种可能性是您的程序使用未初始化的堆数据。 从调试器启动程序会启用 NT 调试堆，这会导致堆分配器使用填充模式填充新的内存块，并且还会启用一些堆检查。 从调试器外部启动相同的程序会禁用 NT 调试堆，但如果该程序与 C 运行时的调试版本链接，则 CRT 调试堆仍将启用。
不太可能的可能性是您的程序需要
SeDebugPrivilege在其进程令牌中设置。 调试器在其进程令牌中启用此特权，这具有副作用：从调试器启动的所有程序都会继承此特权。 如果您的程序尝试使用OpenProcess()/ReadProcessMemory()/WriteProcessMemory()并且没有正确处理错误，则可以想象它可能会崩溃。One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires
SeDebugPrivilegeto be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to useOpenProcess()/ReadProcessMemory()/WriteProcessMemory()and doesn't handle errors correctly, it's conceivable that it could crash.有几种可能性。 除了已经提到的内容之外，从 Visual Studio 运行应用程序将在与 Visual Studio 实例相同的安全上下文中执行。 因此，例如，如果您正在使用 Vista，当您尝试访问受保护的文件或注册表时，可能会遇到未处理的安全违规。
如果您构建一个调试版本并独立运行它会怎样？ 它会崩溃吗？ 如果是这样，您通常可以从那里进入调试器并获取调用堆栈以查看故障所在。
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
从您提供的详细信息来看，听起来可能存在库问题。 您是否在同一台计算机上运行该程序？ 如果没有，那么您还必须为您的应用程序部署适当的库。 如果您在同一台计算机上但在开发环境之外运行，请确保您的应用程序可以看到适当的库。
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
我发现在发布中进行调试的最佳方法是在发生崩溃时创建故障转储，然后该转储允许我在开发计算机上加载调试符号并找出发生了什么。 更多信息请参见：http://www.debuginfo.com/articles/effminidumps.html
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
您也可以转到文件 => 在 Visual Studio 中打开并打开 .exe，因此您不会在调试器本身下启动它。 不确定是否有帮助。
http://blogs.msdn.com/saraford/archive/2008/08/ 21/您是否知道您可以在不使用工具附加到进程的情况下调试不是视觉工作室项目的一部分的可执行文件296。 ASPX
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx