在测试环境之外时程序崩溃 - C++

发布于 2024-11-14 22:31:04 字数 275 浏览 7 评论 0原文

我有一个程序,从 Visual Studio 2010 Express 内部运行时运行得非常好,但在构建和取出时却出现了问题。我已经将外部测试环境设置为与在 Visual Studio 中运行时相同,因此这应该不是问题。我想将其附加到 .exe 以查看崩溃的位置,但我没有非 Express 版本。

有什么建议吗?为什么程序在 VSC++ 2010 Express 环境之外会崩溃,但在内部却可以完美运行。

我会发布代码,但这是一个巨大的项目,而不是会导致错误的行。

非常感谢您抽出时间。

I have a program that runs fantastically when run from inside Visual Studio 2010 Express but when built and taken out, it has problems. I have set up the external test environment the same as when it is run from within Visual Studio so that shouldn't be the problem. I want to attach it to the .exe to see where the crash is but I don't have the non-Express versions.

Any suggestions? Why would a program crash outside of the the VSC++ 2010 Express environment but run perfectly inside.

I would post code but it's a huge project, not a line that would cause an error.

Thank you so much for your time.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

浮光之海 2024-11-21 22:31:04

如果不知道崩溃是什么,就很难确定,但有几个常见问题可能会导致这种情况:

It's very difficult to know for certain without knowing what the crash is, but a couple of common issues that may cause this:

  • Environment variables not the same. Perhaps you are relying on something in vcvars32.bat in your test environment.
  • The PATH environment variable is not the same and your picking up some bad or incompatible DLL.
  • Your code is somehow dependant on the current working directory being the one when run from Visual Studio.
漆黑的白昼 2024-11-21 22:31:04

维基百科来救援

时间也可能是海森错误的一个因素。与正常执行相比,在调试器的控制下执行程序可以改变程序的执行时序。当调试器中单步执行源代码行减慢程序速度时,诸如竞争条件之类的时间敏感错误可能不会重现。当行为涉及与不受调试器控制的实体交互时尤其如此,例如在调试两台机器之间的网络数据包处理且只有一台机器受调试器控制时。

另请注意,User32.dll 在调试器下稍微改变其行为,以便使调试更容易。但这应该不会改变任何事情。

Wikipedia to the rescue?

Time can also be a factor in heisenbugs. Executing a program under control of a debugger can change the execution timing of the program as compared to normal execution. Time-sensitive bugs such as race conditions may not reproduce when the program is slowed down by single-stepping source lines in the debugger. This is particularly true when the behavior involves interaction with an entity not under the control of a debugger, such as when debugging network packet processing between two machines and only one is under debugger control.

Also, note that User32.dll slightly changes its behavior when under a debugger, in order to make debugging easier for you. That shouldn't change anything, though.

温柔戏命师 2024-11-21 22:31:04

您可以使用免费的Windows 调试器工具对此进行调试。有大量可用的文档和快速入门指南,尤其是安装中包含的 chm。对于您的情况,您可能需要尝试以下操作:

  1. 确保您的应用程序的 PDB 在共享位置可用。
  2. 附加到应用程序的运行实例:windbg -p。请注意,您还可以通过执行 windbg -g foo.exe 在调试器上下文中启动程序。
  3. 重现崩溃。
  4. 将符号路径更改为您的符号和 Microsoft 公共符号服务器,以获得组件的正确符号: .sympath x:\YourPathToPDBs; SRV*x:\symbols*http://msdl.microsoft.com/download/symbols
  5. 告诉调试器使用您的路径重新加载符号:.reload
  6. 通过点击 获取调用堆栈>k 在调试器中。

这就是您需要找出崩溃位置的基础知识。然后,您可以更深入地尝试通过查看调试器 chm 或 MSDN 或 苔丝的博客。一个有用的命令是 dv 来转储特定帧的局部变量。如果调用堆栈没有给出行号,请输入 .lines,然后点击 kkb

You could debug this using the freely available Debugger Tools for Windows. There's plenty of documentation and quick start guides available, especially the chm included in the install. In your case, you may want to try the following:

  1. Make sure you have the PDBs for your app available somewhere on a share.
  2. Attach to the running instance of the app: windbg -p <PID>. Note that you can also start the program under the context of the debugger by doing windbg -g foo.exe.
  3. Repro the crash.
  4. Change the symbol path to your symbols and the Microsoft public symbol server to get proper symbols for components: .sympath x:\YourPathToPDBs; SRV*x:\symbols*http://msdl.microsoft.com/download/symbols
  5. Tell the debugger to reload symbols using your path: .reload
  6. Get a callstack by hitting k in the debugger.

That's the barebones you need to figure out where it's crashing. You can then go deeper and try to analyze exactly why it's crashing by looking at the debugger chm or other resources on MSDN or Tess's blog. One useful command is dv to dump local variables for a particular frame. If the callstack doesn't give line numbers, type .lines and then hit k or kb.

呢古 2024-11-21 22:31:04

您可以使用 try catch 块包围 Main 函数中的所有代码。当捕获异常时,将堆栈跟踪写入日志文件。

然后运行您的 exe 并检查日志文件以了解程序崩溃的位置。

PS:不要忘记将 *.pdb 文件与 exe 文件放在一起,否则您将无法获取堆栈跟踪信息。

You could surround all code in your Main function with a try catch block. When you catch an excepcion, write to a log file the stack trace.

Then run your exe and check the log file to know where your program is crashing.

PS: Don't forget to place the *.pdb file together with the exe file, otherwise you won't be able to get the stacktrace information.

一个人的夜不怕黑 2024-11-21 22:31:04

我意识到这个问题已经有几年了,但我也经历过同样的事情,并发现了一个可能的罪魁祸首(在我的例子中是真正的罪魁祸首),这可能会帮助其他有这个问题的人。

在 Visual Studio 中运行应用程序和在外部运行应用程序时的一个重要区别是当前工作目录(“CWD”)。

Visual C++ 解决方案/项目的典型目录结构如下:

Solution     <- the location of your solution file
  Debug      <- where the Debug executables end up
  Release    <- where the Release executables end up
  Project    <- the location of your project file
    Debug    <- where Debug intermediate files end up
    Release  <- where Release intermediate files end up

当您从 Studio 中执行应用程序时,无论是使用“开始调试”还是“启动而不调试”,默认的 CWD 是项目目录,因此在本例中解决方案\项目

但是,当您通过双击应用程序在外部执行时,CWD 是应用程序目录(例如 Solution\Debug)。

如果您尝试从当前目录打开文件(这就是您执行 std::ifstream ifstr("myfile.txt") 时发生的情况),是否成功取决于您所在的位置您启动了该应用程序。

I realise this question is a couple of years old, but I have been experiencing the same thing and came upon a possible culprit (the actual culprit in my case), which may help others who have this issue.

One important difference when running an application within Visual Studio and running it outside is the Current Working Directory ("CWD").

A typical directory structure for a Visual C++ Solution/Project is along these lines:

Solution     <- the location of your solution file
  Debug      <- where the Debug executables end up
  Release    <- where the Release executables end up
  Project    <- the location of your project file
    Debug    <- where Debug intermediate files end up
    Release  <- where Release intermediate files end up

When you execute the application from within Studio, either with "Start Debugging" or "Start Without Debugging", the default CWD is the Project directory, so in this case Solution\Project.

However, when you execute outside by simply double-clicking the application, the CWD is the application directory (Solution\Debug for example).

If you are attempting to open a file from the current directory (which is what happens when you do std::ifstream ifstr("myfile.txt")), whether it succeeds depends on where you were when you started the application.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文