VS2012: Haltepunkt in ntdll.dll beim Start des Debuggers ohne weitere Informationen
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.
4 Antworten
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.
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 .
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.
Das Ändern dieser beiden scheint das Problem tatsächlich für mich gelöst zu haben.
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.
Tags und Links c++ windows visual-studio-2012 debugging windows-8