Come è possibile determinare il motivo per cui il mio processo termina

Question

Ho un problema durante il quale durante la chiamata a una libreria di terze parti il ​​mio processo termina. Non riesco assolutamente a capirlo nel mio debugger. Questo potrebbe essere correlato a questa domanda: How can I debug a win32 process that unexpectedly terminates silently?.

Quando passo a una chiamata in questa libreria, il processo in fase di debug termina semplicemente. Se questa chiusura era dovuta a un'eccezione non gestita o violazione di accesso alla memoria, il debugger l'avrebbe catturato. Quindi la mia ipotesi migliore è che il processo in qualche modo termini normalmente.

quello che ho provato:

• Impostazione punti di interruzione su ExitThread e ExitProcess
• Impostazione gestori per eccezioni non gestite e paramters non validi (set_terminate e _set_invalid_parameter_handler)
• Modifica _set_abort_behavior e _set_error_mode.
• Istruire il debugger per interrompere l'esecuzione su tutte le eccezioni generate.

Ma inutilmente, nessuno dei gestori viene chiamato e nessuno dei punti di interruzione viene attivato.

quello che ho osservato: Quando si blocca il processo, vedo due cose nella finestra di output di debug:

1. Non correlate (vedere Update sotto) vedo EEFileLoadException che sono gettati. Un google veloce di questa eccezione non mi dà una risposta chiara a questa eccezione.

   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x0030b5ac.. 
   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.. 
   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.. 
   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: 0xE0434352: 0xe0434352. 
   

2. Quando termina, tutte le discussioni restituiscono lo stesso codice di errore (STATUS_INVALID_CRUNTIME_PARAMETER). Questo codice di errore indica, per quanto posso dire, che una delle funzioni di runtime c ha ricevuto un parametro non valido e l'applicazione viene chiusa per motivi di sicurezza.

   The thread 'Win32 Thread' (0x12c0) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0xe04) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x53c) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x116c) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x16e0) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x1420) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x13c4) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x40c) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0xc78) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0xd88) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x16c8) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0xcb8) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x584) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x1164) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x1550) has exited with code -1073740777 (0xc0000417). 
   The thread 'Win32 Thread' (0x474) has exited with code -1073740777 (0xc0000417). 
   The program '[5140] Program.exe: Native' has exited with code -1073740777 (0xc0000417). 
   

Quello che voglio davvero sapere è ciò che provoca questo, e facoltativamente; come posso prendere questo nel debugger?

Aggiornamento Per quanto riguarda il EEFileLoadException, è infatti gettato prima che il programma effettua la chiamata che induce a terminare, in modo che non è legata alla terminazione del processo.

Aggiornamento Ho appena letto che set_terminate non funziona nel debugger in modo che è fuori questione. E come notato nel mio commento, i gestori sono gestiti su una base per thread in modo da non avere accesso al gestore in questione.

Inoltre, il programma si blocca molto probabilmente in un thread di lavoro a cui non ho accesso, quindi è difficile impostare qualsiasi punto di interruzione/gestore.

C'è un modo migliore per capire cosa va storto?

Answer 1

eseguire la vostra applicazione debugger NUDER (o connettersi a un processo in esecuzione), premere Ctrl+Alt+E e selezionare le caselle di avere esecuzione fermata debugger su un'eccezione per voi.

Ogni volta che si verifica un'eccezione, il debugger si interrompe. Sarai in grado di verificare gli stati del thread/stack di chiamate per identificare il problema.

ragioni tipiche per un app per terminare in modo imprevisto sono:

• qualcosa di veramente messaggi WM_QUIT messaggio e questo istruisce l'applicazione di chiudere
• un'eccezione avviene, e non viene gestita (specialmente su sfondo. filo); l'eccezione attraversa Stack di chiamate fino al sistema operativo e non sa cosa fare con tutte le cose e solo uccide il processo

Come EEFileLoadException eccezione avviene e non si knnow di cosa si tratta, è forse sarebbe vuoi che la prima cosa capisca se è gestita o meno, se in realtà è una cosa fatale per la tua applicazione.

Answer 2

Ho affrontato lo stesso problema prima. Ho appena cancellato il file obj nel progetto C#. E ricostruire di nuovo e il progetto ha funzionato. Spero che questo risolva il tuo problema.

Answer 3

Configurare procdump per generare un dump del processo al momento della terminazione del processo. Non sono sicuro che VS2010 possa aprire i file di dump, ma windbg può. Quindi scaricare tutti gli stack di thread e si dovrebbe vedere quello che causa la chiusura. Sarai quindi in grado di ispezionare lo stack per trovare l'argomento offendente.

Se la vostra applicazione è foo.exe quindi eseguire ProcDump dal prompt dei comandi come questo: procdump -ma -t -w foo.exe

-ma indica dump completo della memoria

-t indica discarica scrittura a terminazione processo

- w indica di attendere il processo da avviare se non è già in esecuzione

Quindi eseguire l'app all'esterno di di qualsiasi debugger. Una volta terminato, dovresti vedere l'output di procdump che indica che il processo è terminato e che sta scrivendo un file dump.

Ecco il link per ProcDump: http://technet.microsoft.com/en-us/sysinternals/dd996900