VS.Net 2008 Windows 7 调试环境

发布于 2024-10-26 11:55:51 字数 283 浏览 1 评论 0原文

我正在将所有 Windows XP 生产应用程序转换为 Windows 7,但遇到了一些问题。

1:每当我在 XP 机器上遇到错误时,它就会中断执行并停止在有问题的代码行上。在 Windows 7 中,它只是抛出一个通用异常,我不知道发生错误的代码行在哪里。非常令人沮丧。

2:在 XP 中,如果我放置断点或跟踪代码,我可以在运行代码时动态编辑更改。如果我在 Windows 7 中尝试这样做,它会说 64 位应用程序不允许这样做。再次,非常令人沮丧。

有什么解决这些问题或至少解决这些问题的想法吗?

I'm converting all of my Windows XP production applications to Windows 7 and I am having a couple of problems.

1: Whenever I get an error, on the XP machines, it breaks execution and stops on the line of code with the problem. In Windows 7, it just throws a generic exception and I have no idea where the line of code with the error took place. Very frustrating.

2: In XP, I can edit changes on the fly while I am running code if I place breakpoints or follow along the code. If I try that in Windows 7, it says that's not allowed with 64 bit applications. Again, very frustrating.

Any ideas for fixing these problems or at least working around them?

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

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

发布评论

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

评论(2

沦落红尘 2024-11-02 11:55:51

一般来说,这两个平台之间的调试器行为不应该有任何差异。以下是我的建议:

  1. 根据您的描述,我无法确定调试器是否在第一次机会异常时中断,并且没有找到源代码(也许符号未找到/不匹配?)或如果它根本没有破裂的话。如果是前者,请检查“调试 -> Windows -> 模块”并验证是否已为相关模块加载符号。如果是后者,也许 Windows XP 上的调试器被配置为在第一次机会异常时中断,而 Windows 7 上的调试器则不是?比较“调试->例外”下的设置,看看是否有任何差异。请注意,如果您在“工具 -> 选项 -> 调试 -> 常规”中启用了“仅我的代码”,这也会影响调试器在第一次出现异常时的中断行为。

  2. 64 位进程不支持“编辑并继续”功能,因此当您在调试 64 位进程时尝试修改源代码时,调试器会通知您。这可能是运行应用程序的“AnyCPU”(我的猜测)或“x64”版本的结果。编辑并继续工作的唯一方法是调试 32 位进程;这可以通过在“构建 -> 配置管理器”中将目标平台更改为“x86”来完成(如果平台不在列表中,则添加平台)。当然,这假设您的应用程序不依赖于 64 位模块。

There shouldn't be any difference in the debugger's behavior between those two platforms, generally speaking. Here are my suggestions:

  1. From your description, I can't ascertain whether or not the debugger did break on a first chance exception and it didn't find source (perhaps the symbols weren't found / were mismatched?) or if it didn't break at all. If the former, check "Debug -> Windows -> Modules" and verify that the symbols were loaded for the module in question. If the latter, perhaps the debugger on Windows XP was configured to break on a first chance exception while the debugger on Windows 7 was not? Compare the settings under "Debug -> Exceptions" to see if there are any differences. Note that if you have "Just My Code" enabled in "Tools -> Options -> Debugging -> General", this can also affect the breaking behavior of the debugger on first chance exceptions.

  2. The Edit and Continue feature is not supported for 64-bit processes, so the debugger will notify you when you attempt to modify the source code when debugging a 64-bit process. This is likely the result of running an "AnyCPU" (my guess) or "x64" build of your application. The only way for edit and continue to work is to debug a 32-bit process; this can be accomplished by changing the target platform to "x86" in "Build -> Configuration Manager" (add the platform if it isn't in the list). This of course assumes your application is not dependent upon 64-bit modules.

醉殇 2024-11-02 11:55:51

您大致知道错误来自哪里吗?如果是这样,并且尚未完成,请在其周围抛出一个通用的 try catch 并在该 catch 上中断;然后,检查堆栈跟踪以查看哪一行生成了错误。

希望这有帮助。

Do you know roughly where the error is coming from? If so, and not already done, throw a generic try catch around it and break on the catch; then, examine the stack trace to see what line is generating the error.

Hope this helps.

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