Debugger.Launch() stürzt jetzt meinen Windows-Dienst nach dem Upgrade auf .NET 4.0

Question

Für Debugging-Umgebungen haben wir eine bedingte Debugger.Launch-Anweisung im Code, damit Entwickler in den Startup-Code des Windows-Dienstes debuggen können. Wir haben gerade ein Upgrade auf .NET 4.0 durchgeführt. Wenn wir nach dem Upgrade das JIT-Fenster verlassen (d. H., Wir haben uns entschieden, nicht zu debuggen), stürzt der Windows-Dienst ab (der Prozess wird beendet). Früher wurde es einfach fortgesetzt. Wenn wir akzeptieren, anzuhängen, endet die Anwendung nicht und funktioniert gut.

EDIT

Eine weitere seltsame Sache ist, dass die Ausnahme, die ausgelöst wird, ist nicht mehr eine Einführung für Benutzer Ausnahme. Es ist jetzt eine unbehandelte Microsoft .NET Framework-Ausnahme. Ich habe versucht, einen Versuch zu machen, um ihn zu fangen, um zu sehen, was ich bekomme. Ich kann die Ausnahme nicht abfangen, wenn ich debugged bin, da die Ausnahme zu diesem Zeitpunkt nicht auftritt. Wenn ich versuche, die Ausnahme in einer Datei zu protokollieren, stürzt der Dienst ab und ich bekomme nichts.

Irgendeine Möglichkeit, dies zu beheben? Irgendein Grund dafür?

MEHR INFO

Ich habe gerade eine leere und neue Fenster Formularanwendung.

     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()); 
     } 

Ich bekomme das erste "Hallo". Dann bekomme ich das JIT-Fenster, das besagt, dass eine "unbehandelte Microsoft .NET-Ausnahme aufgetreten ist". Wenn ich nicht anhänge, stürzt es ohne eine Nachricht oder irgendetwas ab.

Ich versuchte WinDbg und was nicht. Ich bin überhaupt nicht mit diesen Werkzeugen vertraut. Hier ist, was ich bekomme. Es ist nicht sehr sinnvoll erscheinen auf allen

 
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 

Dies wird auf mehr als 1 Maschine passiert (jedoch sind sie extreamly ähnlich).

WIEDER MEHR INFO

Diese scheinbar recht einfach zu reproduzieren. Es ist auf mehreren Systemen im Haus aufgetreten, und ich habe Bestätigung von einer externen Partei erhalten, dass das Problem einfach reproduziert werden kann, indem Sie das obige Code-Snippet in einem .NET-Windows-Formular verwenden, das .NET 4.0

Answer 1

verwendet Problem und über einige Googling gefunden Microsoft Connect report for it.