Perché Environment.Exit () non termina più il programma?

Questo è qualcosa che ho scoperto solo pochi giorni fa, ho ottenuto la conferma che non è solo limitato alla mia macchina da questa domanda .

Il modo più semplice per riproporlo è avviando un'applicazione Windows Form, aggiungi un pulsante e scrivi questo codice:

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

Il programma ha esito negativo dopo l'esecuzione dell'istruzione Exit (). Su Windows Form viene visualizzato "Errore durante la creazione dell'handle della finestra".

L'abilitazione del debug non gestito rende in qualche modo chiaro cosa sta succedendo. Il ciclo modale COM è in esecuzione e consente di recapitare un messaggio WM_PAINT. È fatale in una forma eliminata.

Gli unici fatti che ho raccolto finora sono:

• Non si limita solo all'esecuzione con il debugger. Anche questo fallisce senza uno. Anche piuttosto male, la finestra di dialogo di arresto anomalo WER viene visualizzata due volte .
• Non ha nulla a che fare con il testimone del processo. Il livello wow64 è piuttosto noto, ma una build AnyCPU si blocca allo stesso modo.
• Non ha nulla a che fare con la versione .NET, 4.5 e 3.5 si bloccano allo stesso modo.
• Il codice di uscita non ha importanza.
• Chiamare Thread.Sleep () prima di chiamare Exit () non lo risolve.
• Ciò accade sulla versione a 64 bit di Windows 8 e Windows 7 non sembra essere interessato allo stesso modo.
• Questo dovrebbe essere un comportamento relativamente nuovo, non l'ho mai visto prima. Non vedo aggiornamenti pertinenti forniti tramite Windows Update , sebbene la cronologia degli aggiornamenti non sia più accurata sul mio computer.
• Questo è un comportamento gravemente sconvolgente. Scriveresti codice come questo in un gestore eventi per AppDomain.UnhandledException e si arresta in modo anomalo allo stesso modo.

Sono particolarmente interessato a cosa potresti eventualmente fare per evitare questo incidente. In particolare lo scenario AppDomain.UnhandledException mi sorprende; non ci sono molti modi per terminare un programma .NET. Si noti che la chiamata a Application.Exit () o Form.Close () non è valida in un gestore eventi per UnhandledException, quindi non sono soluzioni alternative.

AGGIORNAMENTO: Mehrdad ha sottolineato che il thread del finalizzatore potrebbe essere parte del problema. Penso che sto vedendo questo e sto anche vedendo alcune prove per il timeout di 2 secondi che il CLR fornisce al thread del finalizzatore per terminare l'esecuzione.

Il finalizzatore si trova all'interno di NativeWindow.ForceExitMessageLoop (). C'è una funzione IsWindow () Win32 lì che corrisponde approssimativamente alla posizione del codice, offset 0x3c quando si guarda il codice macchina in modalità 32-bit. Sembra che IsWindow () sia un deadlock. Tuttavia, non riesco a ottenere una buona traccia dello stack per gli interni, il debugger pensa che la chiamata P / Invoke sia appena tornata. Questo è difficile da spiegare. Se riesci a ottenere una traccia dello stack migliore, mi piacerebbe vederlo. Il mio:

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

Nulla al di sopra della chiamata ForceExitMessageLoop, debugger non gestito abilitato.

Ho contattato Microsoft per questo problema e che sembrava aver ripagato. Almeno mi piacerebbe pensarlo :). Anche se non ho ricevuto la conferma di una risoluzione da loro, il gruppo di Windows è difficile da contattare direttamente e ho dovuto usare un intermediario.

Un aggiornamento fornito tramite Windows Update ha risolto il problema. Il notevole ritardo di 2 secondi prima dell'arresto anomalo non è più presente, suggerendo fortemente che il deadlock IsWindow () è stato risolto. E il programma si chiude in modo pulito e affidabile. L'aggiornamento ha installato patch per Windows Defender, wdboot.sys, wdfilter.sys, tcpip.sys, rpcrt4.dll, uxtheme.dll, crypt32.dll e wintrust.dll

Uxtheme.dll è la strana anatra. Implementa l'API di temi degli stili di visualizzazione ed è utilizzato da questo programma di test. Non posso esserne sicuro, ma i miei soldi sono su quello come fonte del problema. La copia in C: \ WINDOWS \ system32 ha il numero di versione 6.2.9200.16660, creato il 14 agosto 2013 sulla mia macchina.

Caso chiuso.

Non so perché non funzioni "più" , ma penso che Environment.Exitesegua i finalizzatori in sospeso. Environment.FailFastnon lo fa.

Potrebbe essere che (per qualche bizzarra ragione) hai strani finalizzatori in sospeso che devono essere eseguiti in seguito, facendo sì che ciò accada.

Questo non spiega perché stia accadendo, ma non chiamerei Environment.Exitun gestore di eventi pulsante come il tuo campione - invece chiudo il modulo principale come suggerito nella risposta di René .

Per quanto riguarda un AppDomain.UnhandledExceptiongestore, forse potresti semplicemente impostare Environment.ExitCodepiuttosto che chiamare Environment.Exit.

Non sono sicuro di ciò che stai cercando di ottenere qui. Perché vuoi restituire un codice di uscita da un'applicazione Windows Form? Normalmente i codici di uscita sono utilizzati dalle applicazioni della console.

Sono particolarmente interessato a cosa potresti eventualmente fare per evitare questo crash. Per impedire la visualizzazione della finestra di dialogo WER, è richiesto Calling Environment.Exit ().

Hai un tentativo / cattura nel metodo principale? Per le applicazioni Windows Form ho sempre un tentativo / catch intorno al ciclo di messaggi, nonché i gestori di eccezioni non gestite.

Ho riscontrato lo stesso problema nella nostra app, lo abbiamo risolto con il seguente costrutto:

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