升级到 .NET 4.0 后,Debugger.Launch() 现在使我的 Windows 服务崩溃

发布于 2024-09-25 00:08:20 字数 2324 浏览 0 评论 0原文

对于调试环境,我们在代码中添加了条件 Debugger.Launch 语句,以允许开发人员调试到 Windows 服务的启动代码。我们今天刚刚升级到 .NET 4.0。升级后,如果我们退出 JIT 窗口(即我们选择不调试),Windows 服务就会崩溃(进程正在终止)。它过去只是简单地恢复。如果我们接受附加,应用程序不会终止并且可以正常工作。

编辑

另一个奇怪的事情是抛出的异常不再是 Launch for User 异常。它现在是一个未处理的 Microsoft .NET 框架异常。我尝试在它周围包裹一个 try catch 来看看我得到了什么。当我调试时我无法捕获异常,因为此时异常没有发生。如果我尝试将异常记录到文件中,服务就会崩溃,我什么也得不到。

有办法解决这个问题吗?有什么理由吗?

更多信息

我刚刚创建了一个空白的新 Windows 窗体应用程序。


        public Form1()
        {
            try
            {
                MessageBox.Show("hello");
                System.Diagnostics.Debugger.Launch();

            }
            catch
            {
                MessageBox.Show("error");
            }
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
            InitializeComponent();
        }

        void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            MessageBox.Show(e.ToString());
        }

我得到第一个“你好”。然后我看到 JIT 窗口,显示“发生了未处理的 Microsoft .NET 异常”。如果我不附加,它就会崩溃,没有任何消息或任何内容。

我尝试了WinDbg,但没有成功。我对这些工具一点也不熟悉。这就是我得到的。它看起来根本没有什么用处

Microsoft (R) Windows 调试器版本 6.12.0002.633 AMD64
版权所有 (c) Microsoft Corporation。版权所有。


加载转储文件 [C:\Users\moueis\TestDebugging_100927_104956.dmp]
具有完整内存的用户迷你转储文件:仅应用程序数据可用

评论: '
*** C:\Users\moueis\Desktop\procdump.exe TestDebugging.exe -e -ma
*** 未处理的异常'
符号搜索路径为:*** 无效 ***
****************************************************** **************************
* 如果没有符号搜索路径,符号加载可能不可靠。 *
* 使用 .symfix 让调试器选择符号路径。 *
* 设置符号路径后,使用 .reload 刷新符号位置。 *
****************************************************** **************************
可执行搜索路径为: 
Windows 7 版本 7600 MP(8 个进程)免费 x64
产品:服务器,套件:TerminalServer SingleUserTS
机器名称:
调试会话时间:2010 年 9 月 27 日星期一 10:49:56.000 (UTC - 4:00)
系统正常运行时间:11 天 20:41:04.714
流程正常运行时间:0 天 0:00:22.000
................................................
*** 错误:找不到符号文件。默认导出 ntdll.dll 的符号 - 
*** 错误:找不到符号文件。默认导出 KERNELBASE.dll 的符号 - 
KERNELBASE!DebugBreak+0x2:
000007fe`fd432442 cc 整数 3

这种情况发生在不止一台机器上(但是,它们非常相似)。

更多信息

这显然很容易重现。它已在内部多个系统上发生,并且我已收到外部方的确认,只需在使用 .NET 4.0 的 .NET windows 窗体中使用上面的代码片段即可重现该问题

For debugging environments, we have a conditional Debugger.Launch statement in the code to allow developers to debug into the startup code of the windows service. We just upgraded to .NET 4.0 today. Since the upgrade, if we exit out of the JIT window (i.e. we chose not to debug), the Windows Service is crashing (process is terminating). It used to simply resume. If we accept to attach, the application does not terminate and works fine.

EDIT

Another strange thing is that the exception that is thrown is no longer a Launch for User exception. It is now an unhandled Microsoft .NET framework exception. I've tried to wrap a try catch arround it to see what i get. I can't catch the exception when i'm debugged in because at that point the exception doesn't occur. If i try to log the exception to a file, the Service crashes and i get nothing.

Any way to fix this? Any reason for it?

MORE INFO

I just created a blank and new windows form application.


        public Form1()
        {
            try
            {
                MessageBox.Show("hello");
                System.Diagnostics.Debugger.Launch();

            }
            catch
            {
                MessageBox.Show("error");
            }
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
            InitializeComponent();
        }

        void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            MessageBox.Show(e.ToString());
        }

I get the first "hello". Then i get the JIT window which says an "unhandled Microsoft .NET exception has occured". If i do not attach, it crashes without a message or anything.

I tried WinDbg and what not. I'm not familiar at all with those tools. Here is what i'm getting. It does not appear very useful at all

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\moueis\TestDebugging_100927_104956.dmp]
User Mini Dump File with Full Memory: Only application data is available

Comment: '
*** C:\Users\moueis\Desktop\procdump.exe  TestDebugging.exe -e -ma
*** Unhandled exception'
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
Windows 7 Version 7600 MP (8 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Mon Sep 27 10:49:56.000 2010 (UTC - 4:00)
System Uptime: 11 days 20:41:04.714
Process Uptime: 0 days 0:00:22.000
.........................................
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for KERNELBASE.dll - 
KERNELBASE!DebugBreak+0x2:
000007fe`fd432442 cc              int     3

This is happening on more than 1 machine (however, they are extreamly similar).

AGAIN MORE INFO

This is apparently pretty easy to reproduce. It has occured on multiple systems in house and I've received confirmation from an external party that the problem can be reproduced simply by using the code snippet above in a .NET windows form that uses .NET 4.0

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

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

发布评论

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

评论(1

哽咽笑 2024-10-02 00:08:20

我遇到了同样的问题,并通过一些谷歌搜索发现 Microsoft Connect 报告

I encountered this same issue and via some Googling found the Microsoft Connect report for it.

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