Esto es algo que descubrí hace unos días, recibí la confirmación de que no se limita a mi máquina desdeesta pregunta.

La forma más fácil de reprocharlo es iniciar una aplicación de Windows Forms, agregar un botón y escribir este código:

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

El programa falladespués se ejecuta la sentencia Exit (). En Windows Forms aparece el mensaje "Error al crear el identificador de ventana"

Habilitar la depuración no gestionada deja bastante claro lo que está sucediendo. losCOM El bucle modal se está ejecutando y permite que se entregue un mensaje WM_PAINT. Eso es fatal en una forma dispuesta.

Los únicos hechos que he recopilado hasta ahora son:

No se limita a correr con el depurador. Esto también falla sin uno. También bastante mal, aparece el cuadro de diálogo WER crashdos veces.No tiene nada que ver con el bitness del proceso. La capa wow64 es bastante notoria, pero una construcción AnyCPU se bloquea de la misma manera.No tiene nada que ver con la versión .NET, 4.5 y 3.5 se bloquean de la misma manera.El código de salida no importa.Llamar a Thread.Sleep () antes de llamar a Exit () no lo arregla.Esto sucede en la versión de 64 bits de Windows 8, y parece que Windows 7 no se ve afectado de la misma manera.Esto debería ser un comportamiento relativamente nuevo, no lo he visto antes. No veo actualizaciones relevantes entregadas a través deactualizacion de Windows, aunque el historial de actualizaciones ya no es exacto en mi máquina.Este es un comportamiento grosero. Escribiría un código como este en un controlador de eventos para AppDomain.UnhandledException, y se bloquea de la misma manera.

Estoy particularmente interesado en lo que podrías hacer para evitar este choque. Particularmente el escenario AppDomain.UnhandledException me deja perplejo; no hay muchas maneras de terminar un programa .NET. Tenga en cuenta que llamar a Application.Exit () o Form.Close () no es válido en un controlador de eventos para UnhandledException, por lo que no son soluciones alternativas.

ACTUALIZACIÓN: Mehrdad señaló que el hilo finalizador podría ser parte del problema. Creo que estoy viendo esto y también estoy viendo algunas pruebas del tiempo de espera de 2 segundos que el CLR le da al subproceso finalizador para que termine de ejecutarse.

El finalizador está dentro de NativeWindow.ForceExitMessageLoop (). Hay una función Win32 de IsWindow () que se corresponde aproximadamente con la ubicación del código, compensando 0x3c cuando se mira el código de la máquina en el modo de 32 bits. Parece que IsWindow () está en un punto muerto. No puedo obtener un buen seguimiento de la pila para las partes internas, sin embargo, el depurador piensa queP / Invocar La llamada acaba de regresar. Esto es difícil de explicar. Si puede obtener un mejor seguimiento de pila, entonces me encantaría verlo. Mía:

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

Nada por encima de la llamada ForceExitMessageLoop, depurador no administrado habilitado.