Why does Environment.Exit() not terminate the program any more?

Question

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.

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 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.

Case closed.

I don't know why it doesn't work "any more", but I think Environment.Exit executes pending finalizers. Environment.FailFast doesn't.

It might be that (for some bizarre reason) you have weird pending finalizers that must run afterward, causing this to happen.

This doesn't explain why it's happening, but I wouldn't call Environment.Exit in a button event handler like your sample - instead close the main form as suggested in rene's answer.

As for an AppDomain.UnhandledException handler, maybe you could just set Environment.ExitCode rather than calling Environment.Exit.

I'm not sure what you're trying to achieve here. Why do you want to return an exit code from a Windows Forms application? Normally exit codes are used by console applications.

I'm particularly interested in what you could possibly do to avoid this crash Calling Environment.Exit() is required to prevent the WER dialog from showing.

Do you have a try/catch in the Main method? For Windows Forms applications I always have a try/catch around the message loop as well as the unhandled exception handlers.

I've found same problem in our app, we have resolved it with the following construct:

Environment.ExitCode=1;
Application.Exit();