Debugger.Launch() est maintenant mon service Windows bloque après la mise à niveau 4.0 .NET

Question

Pour les environnements de débogage, nous avons une déclaration de Debugger.Launch conditionnelle dans le code pour permettre aux développeurs de déboguer dans le code de démarrage du service Windows. Nous venons de passer à .NET 4.0 aujourd'hui. Depuis la mise à niveau, si nous sortons de la fenêtre JIT (c'est-à-dire que nous avons choisi de ne pas déboguer), le service Windows plante (le processus se termine). C'était simplement de reprendre. Si nous acceptons de joindre, l'application ne se termine pas et fonctionne bien.

EDIT

Une autre chose étrange est que l'exception qui est levée n'est plus pour le lancement exception de l'utilisateur. Il s'agit maintenant d'une exception de structure Microsoft .NET non gérée. J'ai essayé d'envelopper un essai de l'arround pour voir ce que je reçois. Je ne peux pas attraper l'exception lorsque je suis débogué car à ce stade l'exception ne se produit pas. Si j'essaie de consigner l'exception dans un fichier, le service se bloque et je n'obtiens rien.

Un moyen de résoudre ce problème? Une raison pour cela?

PLUS D'INFO

Je viens de créer une application sous forme de fenêtres en blanc et nouveaux.

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

Je reçois le premier "bonjour". Ensuite, je reçois la fenêtre JIT qui dit qu'une "exception Microsoft .NET non gérée est survenue". Si je ne joins pas, il se bloque sans un message ou quoi que ce soit.

J'ai essayé WinDbg et que non. Je ne connais pas du tout ces outils. Voici ce que je reçois. Il ne semble pas très utile à tous

 
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 

Ceci se produit sur plus de 1 machine (cependant, ils sont extreamly similaires).

ENCORE PLUS D'INFO

Ceci est apparemment assez facile à reproduire. Il a eu lieu sur plusieurs systèmes en interne et j'ai reçu la confirmation d'une partie externe que le problème peut être reproduit simplement en utilisant l'extrait de code ci-dessus dans un formulaire .NET 4.0

Answer 1

J'ai rencontré ce même question et via un certain googling trouvé le Microsoft Connect report for it.