AlessC-MSFT ha scritto:
niddu ha scritto:
Ci sono infinite soluzioni a questo problema - dipende cosa devi monitorare.
hai un'idea di che tipo di problema devi aspettarti?
Se non hai idea di dove cominciare, fai girare l'applicazione attaccata ad un debugger (suggerirei WinDbg) in questo modo, se l'applicazione crasha per un'eccezione non gestita, il debugger ti va in break sull'istruzione che ha generato il problema.
Un'alternativa piu' sofisticata a questa e' di fare girare l'appliazione con un debugger attacato e con gli MDA attivati (cerca su Live Search come fare - c'e' da settare qualche registry key). Questo ti consente di trovare problemi piu' interessanti, come heap corruptions o problemi di signature mismatch con P/Invoke finite male. Questo tipo di bug sono pericolosi, perche' il crash avviene in modo non deterministico quando la memoria corrotta e' riutilizzata, e questo puo' succedere anche ore dopo che la corruzione e' avvenuta. Con gli MDA l'applicazione e' interrotta nel debugger nonappena la potenziale corruzione avviene.
La terza e ultima soluzione e' di scriverti una host application specifica per catturare il tipo di problema che cerchi.
Un esempio di questo e' lo host che Joe Duffy ha scritto per trovare deadlocks in un'applicazione scritta in .NET. In questo caso, l'applicazione host tiene una contabilita' di tutti i lock e solleva un'eccezione nel caso sia individuato un deadlock a runtime invece di mandare l'applicazione in hang.
Dovresti trovare il programma completo di source come allegato ad un articolo su MSDN magazine nel 2005 (credo che fosse la rubrica CLR Inside Out)
Queste sono tutte tecniche che usiamo spesso per trovare i problemi nello stress testing delle applicazioni in MS.
Saluti
--Alessandro
Buona fortuna
Intanto grazie delle risposte.
Anche io sono dell'idea che per monitorare un applicazione sia ideale farlo dall'interno, ma mi è stato chiesto di non toccare il codice di questa applicazione(motivazioni aziendali che non conosco) e di creare un'altra applicazione esterna alla prima che si occupi di monitorare semplicemente se la procedura va a buon fine o se si verificano delle eccezioni, nel qual caso scrivere su un file di log il dettaglio dell'errore.
Ho cominciato a lavorare con i processi di diagnostica, ho lanciato l'applicazione in questione dentro al mio processo e attendo una risposta; il problema è che sia nel caso che vada a buon fine, sia nel caso generi un eccezione l'applicazione di monitoraggio deve aspettare un input da parte dell'utente. vi allego il codice:
Dim Prc As New System.Diagnostics.Process
Dim ProcessStartInfo As New ProcessStartInfo
Prc.StartInfo.UseShellExecute = False
Prc.StartInfo.RedirectStandardError = True
Prc.StartInfo.RedirectStandardInput = True
Prc.StartInfo.RedirectStandardOutput = True
Prc.StartInfo.FileName = "Processo.exe"
Prc.Start()
Prc.WaitForExit()
If Prc.ExitCode <> 0 Then
Dim stdErr As StreamReader = Prc.StandardError
Scrivo l'errore
Else
Dim stdErr As StreamReader = Prc.StandardOutput
Scrivo l'errore
End If
C'è un modo per forzare la chiusura della prima applicazione quando genera un errore senza che l'utente debba dare l'input? oppure esiste una soluzione analoga seguendo un'altra strada?
Grazie
Modificato da niddu il 20 febbraio 2008 12.39 -
