Edit Question - KnowledgeHub

Title Body

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 . 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! } The program fails after the Exit() statement executes. On Windows Forms you get "Error creating window handle". 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: 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 behavi

Tags (comma-separated) Cancel