2013-02-07 14 views
10

Das Problem:Visual Studio 2010 hängt an Verfolgungspunkt

Jedes Mal, wenn ich versuche, einen Trace-Punkt im Debugger zu brechen oder zu setzen, unsere Anwendung und Visual Studio komplett einfriert. Nach dem Trennen des Debuggers wird die Anwendung fortgesetzt.

Dieses Problem hängt wahrscheinlich mit WPF zusammen. Wir haben unsere WinForm-Anwendung nach WPF migriert. Seitdem tritt dieses Problem auf. Aber ich bin nicht in der Lage, den spezifischen Teil des Codes zu finden, der das Problem verursacht. Ich habe bereits Hunderte von Commits zurückgenommen, aber ohne Erfolg.

Es könnte auch mit dem UI-Thread verwandt sein. Wenn der Haltepunkt irgendwo außerhalb der UI-Logik liegt, wird die Anwendung nicht einfrieren, oder sie wird nicht so oft einfrieren wie es irgendwo im UI-Thread der Fall ist.

[Edit:] Ich verwende Windows 7 64bit mit Visual Studio 2010

[Update:]

Wenn Visual Studio hängt, und ich versuche zu lösen, bevor der Haltepunkt angezeigt , Die Nachricht "Kann nicht von einem oder mehreren Prozessen getrennt werden. Alle ausstehenden func-evals wurden nicht abgeschlossen". Aber ich habe alle func-Evaluierung in den Debugging-Optionen deaktiviert. Ich denke mein Problem wird durch eine func_evaluation verursacht, die nicht abgeschlossen werden kann oder die zu einem Timeout führt.

Gibt es eine Möglichkeit zu sehen, auf welcher func_evaluation Visual Studio hängt?

Beispiel:

class SomeUiViewPresenterExample 
{ 
    private Timer m_Timer; 

public void Init() 
{ 
    m_Timer = new Timer(); 
    m_Timer.Elapsed += ElapsedFoo(); 
    m_Timer.AutoReset = false; 
    m_Timer.Interval = 200; 
} 

private void ElapsedFoo(object sender, ElapsedEventArgs elapsedEventArgs) 
{ 
    // there is no code inside this method 
    // On the next line a trace point with "---> ElapsedFoo called" will freeze the debugger 
} 

Was habe ich schon versucht: (ohne Erfolg)

  • aktivieren/deaktivieren Sie den Host-Prozess
  • zu debuggen x86 versucht und x64-Prozesse
  • gestartete Visual Studio mit/SafeMode
  • Update NGEN
  • disabled "Immobilienbewertung und andere implizite Funktionsaufrufe" in Debugging-Optionen
  • deaktiviert Symbol Server
  • deaktiviert Symbol Laden
  • WPF Font-Cache
  • bezeich mehrere UI-Elemente mit ‚DebuggerDisplay gelöscht ("some text ohne Ausdruck")‘

(Ticket Microsoft Connect)

Wahrscheinlich Problem:

Da unsere Anwendung .NET Remoting verwendet, um mit einem anderen Prozess zu kommunizieren, meine mein Problem etwas ähnliches wie here sein. Ich habe alle Anmeldungen für remoteed Ereignisse in einer eigenen Aufgabe platziert, aber ohne Erfolg.

Debugger Ausgabe von Visual Studio gedebuggt:

ich einen Debugger Visual Studio angeschlossen haben und haben einige Ausnahmen beobachtet, (80010005)

, aber ich habe keine Ahnung, wheter sie für relevant sind mein Problem ist oder nicht:

(18d8.1708): C++ EH exception - code e06d7363 (first chance) 
(18d8.1708): C++ EH exception - code e06d7363 (first chance) 
..... // snip 
(18d8.18dc): **Unknown exception - code 80010005 (first chance) 
..... // 20 seconds freeze until breakpoint hit in IDE 

(18d8.18dc): Unknown exception - code 80010005 (first chance) 
(18d8.18dc): C++ EH exception - code e06d7363 (first chance) 
ModLoad: 365f0000 36665000 C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\mcee.dll 

// after continue execution debugger and debugged process freezes forever 

(18d8.18dc): Unknown exception - code 80010005 (first chance) 
ModLoad: 00000000`02b90000 00000000`02c1c000 C:\Windows\SysWOW64\UIAutomationCore.dll 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 
(18d8.1a8c): CLR exception - code e0434352 (first chance) 

Vielen Dank für alle Ideen oder Hinweise

Manuel

+0

Nur ein kleiner Punkt. Wenn Sie WPF verwenden, verwenden Sie 'System.Windows.Threading.DispatcherTimer' (den WPF-Timer) nicht den allgemeinen C# -Timer. Weiß nicht, ob das dein Problem beheben wird. – sircodesalot

+0

Danke für den Hinweis. In diesem Fall sollte der Vorgang jedoch nicht im UI-Thread ausgeführt werden. Dieser Vorgang sollte in einem separaten Thread ausgeführt werden, da er nur den Datenkontext aktualisiert (dauert eine Weile) und das Ereignis "Eigenschaft geändert" auslöst. –

+0

Welche Version von Visual Studio? – OmegaMan

Antwort

1

Vielen Dank für Ihre Hinweise. Endlich habe ich VS 2012 installiert und der Debugger verhält sich nun wie gewohnt. Es scheint wirklich ein Bug/Performance Problem im Visual Studio 2010 Debugger zu sein.

1

Je mehr ich mir das ansehe, desto mehr vermute ich, dass es daran liegt, dass Sie den WPF-Timer nicht verwenden. Wenn Sie versuchen, die reguläre Timer-Klasse anstelle des WPF-Dispatcher-Zeitgebers zu verwenden, besteht das Risiko, dass Sie versuchen, die Benutzeroberfläche eines nicht-ui-Threads zu aktualisieren. Dies könnte möglicherweise die Ursache Ihres Problems sein (Da der DataContext Teil des UI technisch).

Mehr Infos hier:

DispatcherTimer vs a regular Timer in WPF app for a task scheduler

+0

Nein, ich denke, es ist richtig, den Datenkontext von einem nicht UI-Thread zu aktualisieren. –

+0

Richtig, aber wenn Sie sagen: 'if (null! = DataContext)', sieht es so aus, als würden Sie tatsächlich die Eigenschaft view.DataContext treffen und nicht nur den Datenkontext selbst. Versuchen Sie, diese Linie herauszunehmen und zu sehen, was passiert. – sircodesalot

+0

Oder versuchen Sie es einfach mit einem Dispatcher-Timer und sehen Sie, ob das Problem dadurch nicht behoben wird. Ihr Code kann fast identisch bleiben. Ändern Sie einfach den Namen des Timers in System.Windows.Threading.DispatcherTimer. Wenn das der Fall ist, können Sie Code in einem anderen Thread ausführen, Sie müssen nur "Invoke" verwenden, wenn Sie die endgültigen Änderungen am UI-Objekt vornehmen möchten (dh die Ausführung zurück zum Hauptthread verschieben). . – sircodesalot