VS2012: Breakpoint w Ntdll.dll na uruchomienie debuggera bez więcej informacji

Question

Czasami kiedy uruchomić/debug mojej aplikacji w trybie debugowania, używając VS2012, pojawia się okno dialogowe:

<blahblah.exe> jest wyzwalany punkt przerwania.

Nie zawiera żadnych innych informacji, więc trafiam w przerwę, aby zobaczyć, co się dzieje. Och, ale potem otrzymuję komunikat "wntdll.pdb nie załadowany" i nie ma innych informacji na temat problemu. Stos wywołań wskazuje na ntdll.dll i wygląda na to, że moja aplikacja nie rozpoczęła jeszcze jeszcze wykonywania w tym momencie.

Wybór kontynuacji w tym miejscu pozwoli aplikacji/debuggowaniu kontynuować.

Występuje bardzo często (około 7 uruchomień na 10). Mam Windows 8 (64-bit) i Visual Studio 2012 z aktualizacją 1.

Poprzednio miałem Windows 7 (64-bitowy) i VS2010 i nigdy nie miałem tego problemu. Ten konkretny projekt został uaktualniony z wersji, w której został utworzony (2010), więc może to część tego problemu.

Ktoś już napotkał na ten problem? Nie mam pojęcia, gdzie zacząć szukać przyczyny. Choć mam 64-bitowy system Windows, powinienem wspomnieć, że buduję aplikację 32-bitową.

Aktualizacja: Po włączeniu serwerów Microsoft symbolem, oto co stos wywołań wygląda następująco:

> ntdll.dll!_LdrpDoDebuggerBreak@0() Unknown 
    ntdll.dll!_LdrpInitializeProcess@8() Unknown 
    ntdll.dll!__LdrpInitialize@8() Unknown 
    ntdll.dll!_LdrpInitialize@8() Unknown 
    ntdll.dll!_LdrInitializeThunk@8() Unknown 

Powinienem też dodać, na wszelki wypadek, że na pewno mają żadne wartości graniczne ustawione ręcznie wszędzie w moim kodzie.

Answer 1

Ten przykry problem wynika z błędu w programie Visual Studio:

Co się dzieje jest to, że nie jesteśmy prawidłowo obsługiwać wielu ładowarka punktu przerwania zdarzenia z różnych procesów jednocześnie. OS uruchamia punkt przerwania programu ładującego po uruchomieniu procesu, ale przed wykonaniem jakiegokolwiek działania w przypadku debuggerów może zostać zaindeksowany i wykonać inne działanie. Zwykle z powodzeniem pomijamy te (przynajmniej w przypadku pojedynczego uruchamiania). Możesz obejść to , wyłączając opcję "Przerwij wszystkie procesy, gdy jeden proces łamie" w polach narzędzia-> opcje-> debugger. Zauważ też, że nie jest to błąd krytyczny z . Właśnie zatrzymujemy się na wewnętrznym breakpioncie i możesz ponownie nacisnąć F5, aby kontynuować.

Jest to sytuacja wyścigu, więc nie będzie to łatwe dla nas, aby wyśledzić i wykorzystanie multi-launch w VS jest dość niskie, więc mam zamiar nie będzie rozwiązać ten zakładając obejścia powyżej będzie dobry wystarczy, aby odblokować numer , a powrócimy do tego, jeśli zobaczymy więcej raportów od dodatkowych klientów . Czy to brzmi dla ciebie rozsądnie?

Jeszcze raz dziękuję za opinię.

Marc Paine Visual Studio Debugger Inżynieria Menedżer

Źródło: Microsoft Connect

I po porady do dezaktywacji "złamać wszystkie procesy, gdy jeden przerwy procesu" pole wyboru w Visual ustawień Studio Debugger i ten " usunął "problem na razie.

Być może, jeśli uda nam się nakłonić kilka osób do zgłoszenia tego samego problemu/irytacji tego błędu, Microsoft ostatecznie naprawi go tak, jak sugeruje.

Answer 2

Sprawdź, czy włamałeś się do debuggera przy wyjątkach pierwszej szansy.

Można to zobaczyć w sekcji "Debugowanie/wyjątki ...". Sprawdź, czy któreś z pól są zaznaczone. (Przynajmniej była to lokalizacja menu w starszych wersjach VS - obecnie nie mam VS). Włączenie tej opcji powoduje, że debugger ulega przerwaniu, gdy zostanie zgłoszony wyjątek, mimo że może być poprawnie obsługiwany przez aplikację. Jeśli wyłączone, debuger zostanie przerwany tylko wtedy, gdy wyjątek nie zostanie obsłużony. Jeśli są jakieś wyjątki, spróbuj odznacz je i sprawdź, czy nie znikną.

Answer 3

Jeśli uruchomisz aplikację pod debuggerem, pojawi się automatyczny punkt przerwania zaraz po uruchomieniu procesu. Ten punkt przerwania daje możliwość ustawienia kolejnych punktów przerwania przed rozpoczęciem procesu. Jeśli ci się nie podoba, zazwyczaj w debugerze jest opcja ignorowania początkowego domyślnego punktu przerwania. Na przykład w cdbthe option is -g.

Answer 4

Właśnie znalazłem się napotykają podobny problem, choć to był mój callstack:

ntdll.dll!LdrpDoDebuggerBreak() 
ntdll.dll!LdrpInitializeProcess() 
ntdll.dll!_LdrpInitialize() 
ntdll.dll!LdrInitializeThunk() 

W moim przypadku, mój Visual Studio rozwiązanie ma kilka projektów, trzy z tych projektów przedstawionych na start (i debugowania) poprzez ustawienie "Wiele projektów startowych".

Dwa z projektów rozruchowych to (niezarządzane) C++, a jednym z nich jest C#. Byłem w stanie pozbyć się tego punktu przerwania startowego, otwierając właściwości projektu dla projektu C# i włączając "debugowanie kodu natywnego".

Edit: Najwyraźniej nie w pełni rozwiązać mój problem, tylko znacznie zmniejsza częstotliwość ich występowania. Jednak myślę, że to samo ogólne rozwiązanie może go jeszcze naprawić.

Jednym z innych projektów tego rozwiązania jest po prostu wstępnie utworzony plik binarny, który jest uruchamiany ręcznie, określając plik binarny jako projekt TargetPath.

Również zmiana strony Debugger Type na Native Only na stronie właściwości projektu Debugging pomogła.

Więc, zmieniając zarówno tych wydaje się rzeczywiście rozwiązać problem dla mnie.