VS2012: Haltepunkt in ntdll.dll beim Start des Debuggers ohne weitere Informationen

9

Gelegentlich, wenn ich meine Anwendung im Debug-Modus mit VS2012 starte / debugge, erhalte ich einen Dialog:

  

& lt; blahblah.exe & gt; hat einen Haltepunkt ausgelöst.

Es enthält keine weiteren Informationen, also habe ich Pause gemacht, um zu sehen, was vor sich geht. Oh, aber dann bekomme ich "wntdll.pdb nicht geladen", und keine weiteren Informationen zu dem Problem. Der Aufruf-Stack zeigt auf ntdll.dll, und es scheint, dass meine Anwendung zu diesem Zeitpunkt noch nicht einmal die Ausführung begonnen hat.

Wenn Sie an dieser Stelle fortfahren, wird die Anwendung / der Debugger wie gewohnt fortgesetzt.

Dies tritt sehr häufig auf (etwa 7 von 10 Starts). Ich verwende Windows 8 (64-Bit) und Visual Studio 2012 mit Update 1.

Zuvor hatte ich Windows 7 (64-Bit) und VS2010 und habe dieses Problem nie bekommen. Dieses spezielle Projekt wurde von der Version aktualisiert, in der es erstellt wurde (2010), also ist das vielleicht ein Teil des Problems.

Wer ist schon einmal auf dieses Problem gestoßen? Ich habe keine Ahnung, wo ich nach einer Ursache suchen soll. Obwohl ich ein 64-Bit-Windows verwende, sollte ich erwähnen, dass ich eine 32-Bit-Anwendung erstelle.

Aktualisierung: Nachdem Sie die Microsoft Symbol Server aktiviert haben, sehen Sie, wie der Aufruf-Stack aussieht:

%Vor%

Ich sollte auch hinzufügen, nur für den Fall, dass ich definitiv keine Haltepunkte gesetzt habe manuell irgendwo in meinem Code.

    
tacospice 17.01.2013, 10:04
quelle

4 Antworten

1

Dieses lästige Problem rührt von einem Fehler in Visual Studio her:

  

Was passiert, ist, dass wir mehrere Lader nicht richtig handhaben   Breakpoint-Ereignisse von verschiedenen Prozessen gleichzeitig. Das Betriebssystem   löst einen loader breakpoint aus, sobald der Prozess läuft und läuft   bevor eine Ausführung stattfinden kann, damit Debugger installiert werden   Haltepunkte und andere Aktionen. Normalerweise werden wir erfolgreich ignoriert   diese (zumindest in dem einzigen Startfall). Du kannst das umgehen   durch Deaktivieren der "Alle Prozesse brechen, wenn ein Prozess bricht"   Checkbox in Tools- & gt; Optionen- & gt; Debugger. Beachten Sie auch, dass dies kein a   fataler Fehler. Wir stoppen gerade bei einem internen Breakpiont und du kannst   Drücken Sie einfach erneut F5, um weiterzumachen.

     

Es ist eine Race-Condition, also wird es für uns nicht so einfach sein, es zu finden und   Multi-Launch-Nutzung in VS ist ziemlich niedrig, also werde ich das nicht beheben   Wenn Sie davon ausgehen, dass die obige Problemumgehung gut genug ist, um Sie unblockiert zu machen   und wir werden das wiederholen, wenn wir mehr Berichte von zusätzlichen sehen   Kunden. Klingt das für Sie vernünftig?

     

Nochmals vielen Dank für das Feedback.

     

Marc Paine Visual Studio-Debugger-Entwicklungsmanager

Quelle: Microsoft Connect

Ich habe den Ratschlag zum Deaktivieren des Kontrollkästchens "Alle Prozesse brechen, wenn ein Prozess unterbrochen wird" in den Visual Studio Debugger-Einstellungen aktiviert und das Problem vorerst "entfernt".

Wenn wir vielleicht ein paar mehr Leute dazu bringen können, das gleiche Problem / Ärger über diesen Fehler zu melden, wird Microsoft eventuell den Fehler korrigieren, wie sie es vorschlagen.

    
ManuelH 30.05.2017, 07:42
quelle
3

Wenn Sie die Anwendung unter einem Debugger ausführen, gibt es einen automatischen Haltepunkt, sobald der Prozess gestartet wird. Dieser Haltepunkt gibt Ihnen die Möglichkeit, weitere Breakpoints vor der Ausführung des Prozesses zu setzen. Wenn Sie es nicht mögen, gibt es normalerweise eine Option im Debugger, um den ursprünglichen Standardhaltepunkt zu ignorieren. Zum Beispiel in cdb die Option ist -g .

    
Raymond Chen 06.10.2014 13:46
quelle
0

Ich bin gerade auf ein ähnliches Problem gestoßen, aber das war mein Callstack:

%Vor%

In meinem Fall hat meine Visual Studio-Lösung mehrere Projekte, wobei drei dieser Projekte über die Einstellung "Mehrere Startprojekte" der Lösung auf Start (und Debug) eingestellt sind.

Zwei der Start-up-Projekte sind (Unmanaged) C ++, und einer von ihnen ist C #. Ich konnte diesen Startup-Haltepunkt loswerden, indem ich die Projekteigenschaften für das C # -Projekt öffne und das Debuggen von "nativem Code" aktiviere.

" Aktivieren Sie das Debuggen des systemeigenen Codes "checkbox"> </a> </p>

<p> <strong> Bearbeiten </strong>: Offensichtlich löste dies mein Problem nicht vollständig, es reduzierte die Häufigkeit des Auftretens nur sehr stark. Ich denke jedoch, dass die gleiche allgemeine Lösung es immer noch beheben kann. </p>

<p> Eines der anderen Projekte in dieser Lösung ist nur eine vorgefertigte Binärdatei, die gestartet wird, indem die Binärdatei manuell als  <code>TargetPath</code>   des Projekts angegeben wird. </p>

<p> Das Ändern von  <code>Debugger Type</code>   in  <code>Native Only</code>   auf der Eigenschaftsseite  <code>Debugging</code>   des Projekts scheint ebenfalls geholfen zu haben. </p>

<p> <a href="https://i.stack.imgur.com/22hNK.png"> <img src="https://i.stack.imgur.com/22hNK.png" alt =

Das Ändern dieser beiden scheint das Problem tatsächlich für mich gelöst zu haben.

    
404 Not Found 13.01.2017 16:57
quelle
-1

Sehen Sie, ob Sie bei ersten Ausnahmen den Debugger eingeschaltet haben.

Sie können dies unter "Debug / Exceptions ..." sehen. Prüfen Sie, ob eines der Kontrollkästchen aktiviert ist. (Zumindest war das der Menüort in den älteren VS-Varianten - ich habe VS 2012 aktuell nicht) Wenn diese Option aktiviert ist, wird der Debugger unterbrochen, wenn eine Ausnahme ausgelöst wird, obwohl sie von der Anwendung korrekt behandelt wird. Wenn deaktiviert, bricht der Debugger nur, wenn die Ausnahme nicht behandelt wird. Wenn Ausnahmen aktiviert sind, versuchen Sie, sie zu deaktivieren, und prüfen Sie, ob das Problem weiterhin besteht.

    
Nick Nougat 06.10.2014 13:32
quelle