为什么Environment.Exit（）不终止程序了吗？ [英] Why does Environment.Exit() not terminate the program any more?

问题描述

这是我发现的短短数天前，我得到了证实，这并不仅仅局限于我的机器从<一个href=\"http://stackoverflow.com/questions/18036216/win32exception-was-unhandled-visual-basic-when-click-on-exit-button?noredirect=1#comment26385195_18036216\">this问题。

This is something I discovered just a few days ago, I got confirmation that it isn't just limited to my machine from this question.

最简单的方法瑞普是通过启动Windows窗体应用程序，添加一个按钮，然后将这个code：

The easiest way to repro it is by starting a Windows Forms application, add a button and write this code:

    private void button1_Click(object sender, EventArgs e) {
        MessageBox.Show("yada");
        Environment.Exit(1);         // Kaboom!
    }

该计划失败的之后的退出（）语句执行。在Windows窗体你得到错误创建窗口句柄。

The program fails after the Exit() statement executes. On Windows Forms you get "Error creating window handle".

启用非托管调试使得它有点清楚这是怎么回事。该 COM 模式循环正在执行，并允许传递WM_PAINT消息。这是一个形式的处置致命。

Enabling unmanaged debugging makes it somewhat clear what's going on. The COM modal loop is executing and allows a WM_PAINT message to be delivered. That's fatal on a disposed form.

到目前为止，我已经收集的唯一事实是：

The only facts I've gathered so far are:

• 这并不仅仅局限于与调试器中运行。这也失败没有之一。相当差为好，WER崩溃对话框显示出来的两次的


• 这没有什么关系的过程中位数。该WOW64层是pretty臭名昭著，而是值为anycpu构建崩溃一样。


• 它没有任何与.NET版本，4.5和3.5的崩溃一样。


• 退出code无所谓。


• 调用exit（）没有解决之前，调用Thread.sleep（）方法。


• 这发生在Windows 8的64位版本，而Windows 7似乎没有受到影响是一样的。


• 这应该是比较新的行为，我还没有见过这个。我看透的Windows Update 没有提供相关更新，尽管该更新历史记录是不准确的对我机了。


• 这是严重断裂行为。你会写code这样在AppDomain.UnhandledException的事件处理程序，它崩溃了同样的方式。

• It isn't just limited to running with the debugger. This also fails without one. Rather poorly as well, the WER crash dialog shows up twice.
• It doesn't have anything to do with the bitness of the process. The wow64 layer is pretty notorious, but an AnyCPU build crashes the same way.
• It doesn't have anything to do with the .NET version, 4.5 and 3.5 crash the same way.
• The exit code doesn't matter.
• Calling Thread.Sleep() before calling Exit() doesn't fix it.
• This happens on the 64-bit version of Windows 8, and Windows 7 does not seem to be affected the same way.
• This should be relatively new behavior, I haven't seen this before. I see no relevant updates delivered through Windows Update, albeit that the update history isn't accurate on my machine any more.
• This is grossly breaking behavior. You would write code like this in an event handler for AppDomain.UnhandledException, and it crashes the same way.

我在什么你可能做，以避免这种崩溃特别感兴趣。特别是AppDomain.UnhandledException情景树桩我。不会有很多的方法来终止一个.NET程序。请大家注意，调用Application.Exit（）或Form.Close（）不是在UnhandledException事件处理程序有效，所以它们不是解决方法。

I'm particularly interested in what you could possibly do to avoid this crash. Particularly the AppDomain.UnhandledException scenario stumps me; there are not a lot of ways to terminate a .NET program. Please do note that calling Application.Exit() or Form.Close() are not valid in an event handler for UnhandledException, so they are not workarounds.

更新：迈赫达德指出，终结器线程可能是问题的一部分。我想我看到了这个和我也看到了2秒超时的CLR提供了终结器线程执行完一些证据。

UPDATE: Mehrdad pointed out that the finalizer thread could be part of the problem. I think I'm seeing this and am also seeing some evidence for the 2 second timeout that the CLR gives the finalizer thread to finish executing.

终结里面NativeWindow.ForceExitMessageLoop（）。这里有一个IsWindow（）Win32函数那里，大致与code位置对应，在机器code在32位模式下看时偏移0x3C符号。似乎IsWindow（）被死锁。我不能得到不过内部一个很好的堆栈跟踪，调试器认为的P / Invoke 只是调用回。这是很难解释。如果你能得到一个更好的堆栈跟踪那么我很乐意看到它。煤矿：

The finalizer is inside NativeWindow.ForceExitMessageLoop(). There's an IsWindow() Win32 function there that roughly corresponds with the code location, offset 0x3c when looking at the machine code in 32-bit mode. It seems that IsWindow() is deadlocking. I cannot get a good stack trace for the internals however, the debugger thinks the P/Invoke call just returned. This is hard to explain. If you can get a better stack trace then I'd love to see it. Mine:

System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.ForceExitMessageLoop() + 0x3c bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Finalize() + 0x16 bytes
[Native to Managed Transition]
kernel32.dll!@BaseThreadInitThunk@12()  + 0xe bytes
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

在没有来电ForceExitMessageLoop以上，使非托管调试器。

Nothing above the ForceExitMessageLoop call, unmanaged debugger enabled.

推荐答案

我联系了微软关于这个问题，这似乎已见成效。至少我想，认为它确实:)。虽然我没有得到解决，从他们回来的确认，Windows组难以直接联系，我不得不使用的媒介。

I contacted Microsoft about this problem and that seemed to have paid off. At least I'd like to think it did :). Although I didn't get a confirmation of a resolution back from them, the Windows group is difficult to contact directly and I had to use an intermediary.

通过Windows Update提供的更新解决了这个问题。在飞机坠毁前的明显的延迟2秒不再是present，强烈暗示IsWindow（）的僵局得到解决。并且程序干净地并可靠地关闭。 Windows Defender的更新安装的补丁，wdboot.sys，wdfilter.sys，TCPIP.SYS，Rpcrt4.dll中，的uxtheme.dll，crypt32.dll和wintrust.dll

An update delivered through Windows Update solved the problem. The noticeable 2 second delay before the crash is no longer present, strongly suggesting that the IsWindow() deadlock got solved. And the program shuts down cleanly and reliably. The update installed patches for Windows Defender, wdboot.sys, wdfilter.sys, tcpip.sys, rpcrt4.dll, uxtheme.dll, crypt32.dll and wintrust.dll

的Uxtheme.dll是奇逃避。它实现了视觉样式主题化API和使用这个测试程序。我不能肯定，但我的钱是在一个为问题的根源。在C复制：\\ WINDOWS \\ SYSTEM32有版本号6.2.9200.16660，我的机器上2013年8月14日创建的

Uxtheme.dll is the odd-duck out. It implements the Visual Styles theming API and is used by this test program. I can't be sure, but my money is on that one as the source of the problem. The copy in C:\WINDOWS\system32 has version number 6.2.9200.16660, created on August 14th, 2013 on my machine.

结案。

这篇关于为什么Environment.Exit（）不终止程序了吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！