Debugger.Launch() ahora está bloqueando mi servicio de Windows después de actualizar a .NET 4.0

Question

Para depurar entornos, tenemos una declaración Debugger.Launch condicional en el código para permitir a los desarrolladores depurar en el código de inicio del servicio de Windows. Acabamos de actualizar a .NET 4.0 hoy. Desde la actualización, si salimos de la ventana JIT (es decir, elegimos no depurar), el Servicio de Windows se bloquea (el proceso está finalizando). Solía ​​simplemente reanudar. Si aceptamos adjuntar, la aplicación no termina y funciona bien.

EDITAR

Otra cosa extraña es que la excepción que se produce ya no es un lanzamiento de excepción usuario. Ahora es una excepción de marco de Microsoft .NET no controlada. Intenté ajustar una captura de prueba para ver lo que obtengo. No puedo detectar la excepción cuando me depuran porque en ese punto la excepción no ocurre. Si intento registrar la excepción en un archivo, el Servicio falla y no obtengo nada.

¿Alguna manera de arreglar esto? ¿Alguna razón para eso?

MÁS INFORMACIÓN

acabo de crear una aplicación de formulario en blanco y ventanas nuevas.

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

obtengo el primer "hola". Luego aparece la ventana JIT que dice que se ha producido una "excepción no controlada de Microsoft .NET". Si no me adjunto, se bloquea sin un mensaje ni nada.

Intenté WinDbg y qué no. No estoy familiarizado en absoluto con esas herramientas. Esto es lo que obtengo No parece muy útil en absoluto

 
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 

Esto está ocurriendo en más de 1 máquina (sin embargo, son sumamente similares).

VEZ MÁS INFORMACIÓN

Esto es al parecer bastante fácil de reproducir. Se ha producido en varios sistemas internos y he recibido confirmación de una parte externa de que el problema puede reproducirse simplemente utilizando el fragmento de código anterior en un formulario de Windows .NET que usa .NET 4.0

Answer 1

Encontré este mismo problema y a través de Google encontró el Microsoft Connect report for it.