Per gli ambienti di debug, abbiamo un'istruzione Debugger.Launch condizionale nel codice per consentire agli sviluppatori di eseguire il debug nel codice di avvio del servizio Windows. Siamo appena passati a .NET 4.0 oggi. Dopo l'aggiornamento, se usciamo dalla finestra JIT (cioè abbiamo scelto di non eseguire il debug), il servizio di Windows si arresta in modo anomalo (il processo sta terminando). Semplicemente riprendeva. Se accettiamo di allegare, l'applicazione non termina e funziona correttamente.Debugger.Launch() sta bloccando il servizio Windows dopo l'aggiornamento a .NET 4.0
EDIT
Un'altra cosa strana è che l'eccezione che viene generata non è più un lancio per Eccezione utente. Ora è un'eccezione di framework Microsoft .NET non gestita. Ho provato a fare un tentativo di catturarlo per vedere cosa ottengo. Non riesco a rilevare l'eccezione quando sono sottoposto a debug perché a quel punto l'eccezione non si verifica. Se provo a registrare l'eccezione su un file, il servizio si blocca e non ottengo nulla.
Un modo per risolvere il problema? Qualche ragione per questo?
INFO
Ho appena creato un'applicazione modulo vuoto e le nuove finestre.
public Form1()
{
try
{
MessageBox.Show("hello");
System.Diagnostics.Debugger.Launch();
}
catch
{
MessageBox.Show("error");
}
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
InitializeComponent();
}
void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
MessageBox.Show(e.ToString());
}
Ottengo il primo "buongiorno". Poi ottengo la finestra JIT che dice che è avvenuta una "eccezione Microsoft .NET non gestita". Se non lo collego, si blocca senza un messaggio o altro.
Ho provato WinDbg e cosa no. Non sono affatto familiare con quegli strumenti. Ecco cosa sto ottenendo. Non risulta molto utile a tutti
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\moueis\TestDebugging_100927_104956.dmp] User Mini Dump File with Full Memory: Only application data is available Comment: ' *** C:\Users\moueis\Desktop\procdump.exe TestDebugging.exe -e -ma *** Unhandled exception' Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * **************************************************************************** Executable search path is: Windows 7 Version 7600 MP (8 procs) Free x64 Product: Server, suite: TerminalServer SingleUserTS Machine Name: Debug session time: Mon Sep 27 10:49:56.000 2010 (UTC - 4:00) System Uptime: 11 days 20:41:04.714 Process Uptime: 0 days 0:00:22.000 ......................................... *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - *** ERROR: Symbol file could not be found. Defaulted to export symbols for KERNELBASE.dll - KERNELBASE!DebugBreak+0x2: 000007fe`fd432442 cc int 3
Ciò avviene su più di 1 macchina (tuttavia, sono extreamly simili).
ANCORA MAGGIORI INFORMAZIONI
Questo è apparentemente abbastanza facile da riprodurre. Si è verificato su più sistemi in casa e ho ricevuto conferma da una parte esterna che il problema può essere riprodotto semplicemente utilizzando il frammento di codice sopra in un modulo di Windows .NET che utilizza .NET 4.0
Invia la traccia dello stack dell'eccezione e il messaggio di eccezione. –
Che cosa ti dice il registro eventi? –
È possibile eseguire un dump della memoria del servizio quando si blocca utilizzando l'utilità ProcDump di Sysinternal (utilizzando l'opzione -e). Dopo aver ottenuto il dump, è possibile caricarlo in WinDbg e indagare sul motivo del suo arresto anomalo utilizzando l'estensione del debugger SOS. – Liran