Tryb debugowania Windows 7

Tryb debugowania Windows 7

Wszystkie dostępne systemy z rodziny Windows®, oprócz normalnego trybu uruchomienia, mają zaimplementowane inne metody umożliwiające rozruch systemu, z zależności zaistniałych okoliczności i potrzeb.

TRYB DEBUGOWANIA - uruchomienie w tym trybie, powoduje zainicjowanie procesu sprawdzania i próby naprawy jądra (debugowania).

TRYB AWARYJNY - ten tryb pracy systemu, jest przeznaczony do diagnozy i usuwania problemów działania lub uruchamiania systemu. Ze względu na specyficzny sposób ładowania usług i programów, pozwala na uruchomienie systemu nawet w przypadku poważnych problemów, związanych ze sterownikami lub programami.

Aby przejść do trybu awaryjnego, należy użyć klawisza F8, po pojawieniu się komunikatu "Aby zobaczyć opcje rozwiązywania problemów i zaawansowane opcje uruchamiania …" dla WINDOWS 2000 i także F8 po tuż po zainicjowaniu przez BIOS zainstalowanych urządzeń dla pozostałych systemów. Wtedy zostanie wyświetlone menu z omawianymi opcjami, i z trybem awaryjnym, lub wyjść z menu klawiszem ESC.

TRYB AWARYJNY Z OBSŁUGA SIECI - bardzo zbliżony w działaniu i funkcjonalności do standardowego trybu awaryjnego, z tą różnicą, że są ładowane dodatkowe usługi pozwalające na poruszanie się w sieci.

TRYB AWARYJNY Z WIERSZEM POLECENIA - po załadowaniu tego trybu, nie mamy możliwości korzystania z myszy, gdyż EXPLORER.EXE (czyli między innymi Pulpit) nie zostaje załadowany.

WŁĄCZ REJESTRACJĘ ROZRUCHU - proces normalnego rozruchu systemu.

WŁĄCZ TRYB VGA - uruchamia system z wykorzystaniem podstawowego sterownika karty graficznej (najczęściej w najniższej rozdzielczości i z użyciem minimalnej liczby kolorów).

TRYB ODZYSKIWANIA USŁUG KATALOGOWYCH - odnosi się jedynie do domen Windows 2000 i XP.

Na podstawie działania różnych systemów, można zaobserwować pewne różnice w uruchamianiu trybu awaryjnego. Otóż Windows 2000, XP; nie stosują automatycznego uruchomieniu trybu awaryjnego po niepowodzeniu załadowania systemu, jak to miało miejsce w Windows 98. Aby wymusić wywołanie trybu awaryjnego, należy skorzystać z menu zaawansowanych opcji uruchamiania.

Tryb awaryjny spowoduje załadowanie niezbędnych sterowników i usług (mysz, klawiatura, cd - rom, standardowe sterowniki VGA, dziennik zdarzeń, Plug and Play, RPC - zdalne wywołanie procedur, Menedżer dysku logicznego). Programy określone w folderach StartUp (i rejestrze) jako programy uruchamiające się automatycznie podczas startu systemu, a mogące powodować problemy, nie zostają uruchamiane.

Te właściwości sprawiają, że tryb awaryjny jest szczególnie przydatny do rozwiązywania problemów spowodowanych przez automatycznie uruchamiane aplikacje, uszkodzone sterowniki i usługi. Tryb ten ponadto, daje możliwość modyfikacji konfiguracji systemu, a następnie powtórne uruchomienie, już w trybie normalnym.

Dlaczego ktoś by w ogóle chciał debugować jądro systemu operacyjnego?

Debugowanie jądra systemu operacyjnego jest niezbędne do rozwiązania dużej liczby problemów związanych z trybem jądra:odczytu danych z / zapisu danych do przestrzeni adresowej trybu jądra,opracowania sterownika trybu jądra,analizy oprogramowania złośliwego działającego w trybie jądra.

Po drugie, każdy ustawiony breakpoint zatrzyma system. Dlatego właśnie potrzebujesz drugiej maszyny. Największe możliwości daje rozwiązanie zbudowane z maszyn fizycznych, jednak podnosi ono koszty zbudowania kompletnego środowiska ze względu na konieczność posiadania drugiego komputera. Alternatywnym rozwiązaniem jest użycie maszyny wirtualnej lub… wirtualizacja całego środowiska.

Środowisko

Środowisko fizyczne

Aby skonfigurować środowisko fizyczne, potrzebujesz dwóch komputerów: hosta (debugger) i debugowaną maszynę (debugee). Wbrew pozorom nie istnieje z góry narzucony przymus, aby utrzymywać wspólną wersję i architekturę systemu operacyjnego pomiędzy dwoma maszynami. Istotny jest ten sam typ połączenia między tymi maszynami.

Obsługiwanymi typami połączeń są Ethernet, port szeregowy, IEEE 1394 (FireWire) oraz USB (w wersji 2.0 lub nowszej). Poniższa tabela prezentuje istotne cechy dopuszczalnych rozwiązań.

Połączenie	Niezawodność	Szybkość	Dodatkowe informacje
Ethernet	Stabilne	Szybkie	Konieczne wsparcie dla karty sieciowej
Serial	Bardzo stabilne	Bardzo wolne	Umożliwia debugowanie na bardzo niskim poziomie,np. zarządzanie zasilaniemmoże być niedostępne w najnowszych komputerach
IEEE 1394	Bardzo stabilne	Szybkie	Może być wykorzystane z wykorzystaniem kart rozszerzeń
USB	Mogą wystąpić problemy	Szybkie	Konieczny specjalny kabel USB

Istnieją pewne uwagi związane z wykorzystaniem niektórych typów połączeń, o których należy pamiętać. Interfejs USB 2.0 jest dopuszczony do użycia tylko w przypadku, jeżeli jest to port nr 1. Konieczne jest również użycie kabla krosowanego. Jeśli jednak zdecydowałeś się na korzystanie z Ethernetu, powinieneś sprawdzić, czy zadeklarowano wsparcie dla posiadanego modelu karty sieciowej.

Jeśli wybrano już typ połączenia, wystarczy połączyć dwa komputery za jego pomocą.

Środowisko wirtualne

Debugowanie maszyny wirtualnej jest znacznie tańsze niż utrzymanie dodatkowych urządzeń fizycznych. Oczywiście fizyczny host nie musi być obsługiwany przez system Windows. Uniwersalnym rozwiązaniem jest połączenie gości (debuggera oraz maszyny debugowanej) za pomocą wirtualnego połączenia sieciowego.

Istnieją pewne założenia wstępne, którymi posłużono się projektując środowisko debugowania:host jest maszyną z systemem Linux i VirtualBox,debuggerem jest maszyną wirtualną z systemem Windows 10,debuggee to maszyna wirtualna z systemem Windows 10,debugger i debugee są połączone za pośrednictwem wirtualnej karty sieciowej.

Jeśli napotkasz jakiekolwiek problemy z komunikacją pomiędzy maszynami podczas korzystania z tego rozwiązania, upewnij się, że Twoja karta sieciowa jest obsługiwana.

Następna część artykułu prezentuje przygotowanie i konfigurację środowiska wirtualnego.

Konfiguracja środowiska wirtualnego

Przygotowanie debuggera

Pobierz i zainstaluj Windows 10 SDK .Po zainstalowaniu wszystkie potrzebne narzędzia powinny być dostępne w katalogu C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\ .Utwórz katalog do cache’owania symboli, np.

Rozpoczęcie debugowania jądra systemu Windows

Jeżeli nie napisano wyraźnie inaczej, poniższe działania powinny być wykonywane na debuggerze.

Uruchom WinDBG znajdujący się w lokalizacji C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe.Z menu File wybierz ‘Kernel Debug’.W zakładce ‘NET’ ustaw pole ‘Key’ jako ‘Win.Kernel.Debug.Env’.Wciśnij OK.Zrestartuj debugowaną maszynę i poczekaj.Po kilku sekundach powinieneś zobaczyć:

W tym momencie powinno być możliwe skuteczne przetestowanie możliwości debugowania jądra.

Test

W WinDBG wybierz Break z menu Debug lub po prostu naciśnij Ctrl + B.Spróbuj uruchomić dowolne polecenie w sesji windbg, np. Jeśli widzisz listę podobną do poniższej, wszystko jest w porządku.

Jeśli będziesz mieć problem z symbolami jak na rysunku poniżejmożesz naprawić załadowane symbole, uruchamiając polecenia w sesji windbg:

WIERSZ POLECEŃ

WIERSZ POLECEŃ - to aplikacja, która pozwala wprowadzać komendy, aby wywołać określone stany systemu. Obsługa wiersza poleceń daje użytkownikowi duże możliwości ale jednocześnie wymaga ogromnej wiedzy i praktyki.

Interpreter poleceń jest podstawą systemów operacyjnych takich jak DOS czy UNIX, natomiast w systemach okienkowych (z interfejsem graficznym), nie jest on już podstawowym sposobem na zarządzanie systemem. W jego miejsce pojawiły się menedżery okienkowe, znacznie upraszczające pracę.

W Windows 98, interpreter poleceń ładuje się z dyskietki, na której są zawarte programy (okrojona wersja systemu DOS) umożliwiające przeprowadzenie czynności naprawczych systemu, usunięcie wirusów, skasowanie plików, modyfikacje rejestru czy wreszcie uruchomić programy diagnostyczne w celu wykonania operacji niemożliwych w środowisku graficznym.

W systemach NT (Windows 2000, NT, XP), zaimplementowano szczególny rodzaj wiersza poleceń - (dla celów diagnostycznych) - konsolę odzyskiwania.

KONSOLA ODZYSKIWANIA

KONSOLA ODZYSKIWANIA - jest to środowisko podobne do wiersza poleceń, jednakże całkowicie od niego niezależna. Jej zastosowanie to przede wszystkim do zadań diagnostyczno - konserwacyjnych i umożliwia administratorowi dostęp do dysku twardego (bez względu na stosowany system formatowania).

Konsoli używa się niezależnie od działania systemu, to sprawia że jest ona narzędziem służącym przede wszystkim do naprawy konfiguracji systemu oraz jego kalibracji, gdy któraś z usług "blokuje" system. Z konsoli, korzystać mogą tylko administratorzy (ze względu na konieczność logowania), a czynności jakie mogą wykonać to między innymi: zarządzanie plikami i folderami, uruchamianie i zatrzymywać usługi oraz naprawia systemu, jest także możliwość naprawy sektoru startowego i MBR oraz sformatowanie woluminów.

1. Start z instalacyjnych bootdisków lub CD Windows: Metoda uniwersalna.
2. Zainstalowanie Konsoli jako jednej z opcji startowych: Metoda wybiórcza (nie zadziała gdy np. mamy uszkodzony obszar rozruchowy dysku).

Po udanym uruchomieniu, konsola pokazuje listę dostępnych instalacji systemów Windows. Należy się odwołać do tej, która wymaga naprawy lub zmian, wprowadzając odpowiednią cyfrę i zatwierdzając wybór klawiszem ENTER. Jeżeli nie zostanie wskazana instalacja, to naciśnięcie ENTER spowoduje restart komputera.

Po wybraniu instalacji, konsola zażąda podania hasła administratora, które jeżeli zostanie wpisane niepoprawnie trzy razy, konsola zablokuje dostęp do dysków, a następnie zrestartuje komputer. W przypadku poważnych uszkodzeń: utrata lub uszkodzenie rejestru, brak dostępnych instalacji do których się można odwołać, to konsola uruchomi się w katalogu głównym bez żądania podania hasła. W takich przypadkach mamy ograniczone możliwości naprawy instalacji oraz brak dostępu do folderów (co wynika z sytuacji braku systemu).

Podczas korzystania z konsoli, mamy możliwość kopiowania plików na dysk twardy z dyskietki lub płyty, a także kopiować dane między dyskami. Jest dostępnych wiele poleceń, jednakże jeżeli podczas próby wykonania jakiegoś polecenia zostanie wyświetlony komunikat "Odmowa dostępu" oznacza to, że konsola nie akceptuje tego rozkazu.

Konsola daje szerokie możliwości, ale jedynie przy użyciu zaimplementowanych (dopuszczalnych) poleceń - Attrib, Batch, Cd lub Chdir, Chkdsk, Cls, Copy, Del lub Delete, Dir, Disable, Diskpart, Enable, Exit, Expand, Fixboot, Fixmbr, Format, Help, Listsvc, Logon, Map, Md lub Mkdir, More lub Type, Rd lub Rmdir, Ren lub Rename, Set, Systemroot.

Jeżeli zajdzie potrzeba użycia jakiegoś polecenia, lecz nie wiemy jakie ma ono opcje lub jak działa, możemy skorzystać z systemu pomocy do danego polecenia. Aby go użyć, wpisujemy polecenie z parametrem "/?", np.: diskpart /? Lub diskpart help.

Przebieg debugowania

Debugowanie aplikacji to proces związany z naprawą błędów w kodzie, przez co jest zazwyczaj bardzo nielubiany przez programistów. Postaram się jednak przybliżyć ten temat tak, by stał się bardziej zrozumiały oraz pokazać kilka sztuczek, które powinny sprawić, że będzie on dużo szybszy i bardziej efektywny.

Zgodnie z definicją debugowanie to proces polegający na systematycznej redukcji liczby błędów w oprogramowaniu. Przeprowadzany jest zazwyczaj z kontrolowanym wykonaniem kodu aplikacji przy wykorzystaniu debuggera.

Samo słowo bug (z ang. robak), rozumiane jako błąd po raz pierwszy zostało użyte już w IX wieku przez Tomasza Edisona, który w jednym ze swoich listów określił nim usterki techniczne. Jednak jego popularyzację zawdzięczamy admirał Grace Hopper. Razem ze swoimi współpracownikami w latach 40-tych ubiegłego wieku w komputerze Mark II znalazła ćmę, która zaplątała się w przekaźnik, powodując błędy. Admirał nazwała pozbycie się robaka debugowaniem, czyli odrobaczaniem.

Każdy problem wymaga indywidualnego podejścia, jednak mimo to zazwyczaj proces od znalezienia błędu do jego naprawy można podzielić na 5 głównych etapów:

1. Reprodukcja błędu
2. Wyizolowanie źródła błędu
3. Identyfikacja przyczyny awarii
4. Usunięcie defektu
5. Weryfikacja powodzenia naprawy

To pierwszy i ważny etap naprawy błędu. Zdarza się bowiem, że zgłaszane problemy tak naprawdę nie są błędami i wynikają z braku zrozumienia działania aplikacji. Zdarza się również, że odtworzenia błędu na środowisku u programisty jest bardzo trudne.

Spowodowane jest to najczęściej inną konfiguracją środowiska niż środowisko produkcyjne lub brakiem odpowiednich danych. Żeby ułatwić sobie ten proces, najczęściej wykorzystuje się zrzuty bazy danych ze środowiska, na którym znaleziono błąd lub przeprowadza się zdalne debugowanie.

Kiedy uda się już odtworzyć błąd, trzeba ustalić dokładnie, w jakich warunkach on zachodzi. Na tym etapie szukamy minimalnych warunków, jakie muszą być spełnione, żeby wywołać dany błąd.

Mając już wyizolowane źródło błędu, przystępujemy do jego szukania w kodzie. Najczęściej wykorzystuje się do tego debugger lub przegląda się szczegółowe logi.

Po znalezienie dokładnego miejsca powodującego błąd trzeba podjąć decyzję, jak go naprawić. Trzeba bardzo uważać, ponieważ naprawiając jeden fragment kodu, można jednocześnie wywołać błędy w innych, teoretycznie niepowiązanych, miejscach.

Po usunięciu błędu trzeba jeszcze potwierdzić, czy system działa w pełni poprawnie oraz czy nie wywołało to innych niepożądanych skutków.

Techniki debugowania

Ze względu na przyjętą technikę oraz wykorzystane narzędzia, można wyróżnić kilka głównych podejść do debugowania problemu:

• Printf debugging
• Z debuggerem
• Zdalne debugowanie
• Poawaryjne debugowanie (post-mortem)
• Debugowanie przez wykluczenie

Printf debuggingNazwa printf debugging pochodzi od wykorzystania funkcji printf z C. Jednak niezależnie od wyboru konkretnej metody, czy to System.out.println(), logger.debug(), czy języka programowania, zasada pozostaje taka sama. Powstałe w ten sposób logi można przeglądać w wersji online, jednocześnie korzystając z aplikacji i wywołując wybrane funkcjonalności, żeby spowodować błędy lub w formie zrzutu już po wystąpieniu błędu.

Z debuggeremNajczęstsza i zazwyczaj najbardziej komfortowa forma debugowania. Dzięki wykorzystaniu debuggera podłączonego do aplikacji można sterować jej wykonaniem, wykonywać instrukcja programu krok po kroku oraz podglądać wartości poszczególnych zmiennych

Zdalne debugowanieJeżeli nie można odtworzyć błędu na lokalnym komputerze można spróbować połączyć się debuggerem do zdalnej maszyny. Takie działanie jest prawie identyczne jak w przypadku debugowania aplikacji lokalnej, jednak w tym wypadku aplikacja znajduje się na osobnej maszynie i debugger musi sterować jej wykonaniem przez sieć. Może to powodować dodatkowe problemy oraz narzuty wydajnościowe związane z samym wykorzystaniem sieci.

Poawaryjne debugowanie (post-mortem)W tym wypadku, jeżeli już doszło do awarii, można próbować dojść, co dokładnie się stało, dzięki różnego rodzaju zrzutom danych, które zostały zrobione bezpośrednio przed lub już w trakcie awarii.

W tym celu najczęściej wykorzystane są zrzuty pamięci (heap dump) lub zrzut wątków z maszyny wirtualnej Javy (thread dump).

Debugowanie przez wykluczenie polega na próbie izolacji przyczyny powodującej błąd. Można to przeprowadzić np. poprzez wyłączanie kolejnych modułów aplikacji i weryfikację, czy błąd nadal występuje.

Taki sposób debugowanie nazywany jest również debugowaniem z wykorzystaniem algorytmu: Wolf fence.

Debugger

Ponieważ debugowanie z wykorzystaniem debuggera daje największe możliwości, przyjrzymy mu się bliżej. W przykładach posłużę się wbudowanych debuggerem w Netbeans IDE.

Netbeans IDEDebugger w Netbeans daje bardzo dużo możliwości i jest bardzo dobrze zintegrowany z IDE. Dzięki temu naprawdę rzadko potrzebne są jakieś zewnętrzne narzędzia.

W celu uruchomienia projektu w trybie debug można skorzystać z menu głównego Debug lub przycisku jak na grafice poniżej.

Netbeans daje możliwość debugowania aktualnie otwartego projektu lub połączenie się debuggerem do zdalnego procesu.

Bardzo przydatną opcją jest również debugowanie testów jednostkowych. W tym celu na wybranym teście można skorzystać z menu kontekstowego i wybrać opcję: Debug Test File.

Po uruchomieniu aplikacji w debuggerze będzie ona normalnie się wykonywała, aż natrafi na breakpoint. Na widoku powyżej pokazany jest screen z debuggera zatrzymanego na breakpoincie.

W tym momencie można podejrzeć, w jakim dokładnie stanie jest aplikacja. Okno debugging - pokazuje stos wywołań do aktualnego miejsca wykonywania aplikacji. BreakpointBreakpoint, czyli punkt wstrzymania pozwala na zatrzymanie wykonywania aplikacji we wskazanym przez nas miejscu. Aplikacja wtedy przekazuje sterowanie do debuggera, a my możemy podejrzeć aktualny stan aplikacji, czyli np. wszystkie dostępne zmienne.

Gdzie można postawić breakpoint?Breakpointy ustawiamy w linijkach, które zawierają jakiś kod do wykonania. To znaczy, że nie zatrzymamy aplikacji na klamerkach, czy na pustej sygnaturze metody.

Warto zauważyć, że żeby w danym breakpoincie zatrzymała się nasza aplikacja, to wskazany przez niego kod musi się wykonać. Jeżeli więc postawimy breakpoint np. w if'ie i nie zostaną spełnione wymagane warunki, to nasz punkt zatrzymania zostanie pominięty.

Gdzie należy postawić breakpoint?Głowna zasada jest taka, że breakpoint stawiamy przed miejscem, które chcemy podejrzeć. Ponieważ po zatrzymaniu działania programu nie można się już cofnąć, czasem nawet lepiej jest ustawić kilka nadmiarowych breakpointów lub trochę za wcześnie zatrzymać aplikację, żeby złapać ten właściwy moment.

Działanie programu wstrzymywane jest dokładnie przed wybraną linią, czyli linijka oznaczona breakpointem w momencie zatrzymania się, nie jest jeszcze wykonana.

Jak dodać breakpoint?Nowy breakpoint możemy dodać, wskazując wybraną linijkę i wybierając z menu kontekstowego: Toggle Line Breakpoint. Alternatywnie można również kliknąć na numer z lewej strony widoku, oznaczający kolejną linijkę kodu.

Po dodaniu breakpointu linijka zostanie oznaczona na czerwono, a przy numerze linii pojawi się czerwony kwadrat.

W analogiczny sposób usuwamy wybrane breakpointy.

Wiele ciekawych możliwości daje również widok Breakpoints - można go włączyć przez menu główne Window -> Debugging -> Breakpoints. Z tego poziomu widać wszystkie dodane wcześniej breakpointy, można je usunąć, tymczasowo wyłączyć lub dodać nowe.

Podczas debugowania bardzo często poruszamy się po kodzie aplikacji w kontrolowany sposób. Step Over Expression (Shift + F8) - ta opcja wykorzystywana jest, jeżeli w jednej linijce mamy wyrażenia składające się z kilku różnych wywołań. Step Into (F7) - przechodzi linijkę dalej i wykonuje jedną operację - jeżeli ta linijka jest wywołaniem funkcji, przechodzi do jej wnętrza. Step Out (Ctrl + F7) - kontynuuje działanie aż do końca aktualnie wykonywanej metody. W praktyce najczęściej wykorzystywane jest Continue, Step Over oraz Step Into - dlatego warto nauczyć się ich skrótów klawiszowych.

Sztuczki i kruczki debugowania

Dlaczego to tak wolno działa?Uruchomienia aplikacji w trybie debugowania sprawia, że jest ona całkowicie inaczej traktowana przez maszynę wirtualną Javy. Debugowanie wymusza przekazywanie między nimi dużo większej ilości informacji, nie jest również przeprowadzana wewnętrznie standardowa optymalizacja. To wszystko przekłada się na wolniejsze wykonywanie się debugowanej aplikacji.

W celu przyspieszenia warto też usunąć wszystkie niepotrzebne breakpointy. Takie rozwiązania są bardzo przydatne w większych projektach, gdzie zbudowanie na nowo i zrestartowanie całej aplikacji z nowym kodem zajmuje sporo czasu.

Rozproszone debugowanieW środowisku rozproszonym debugowanie jest jeszcze trudniejsze. Czasami dochodzi wręcz do sytuacji, że uruchamia się aplikację w trybie debugowania na kilku różnych komputerach i biega między nimi, żeby puścić dalej wykonywanie debuggera 🙂

W takich sytuacjach można spróbować ograniczyć się do debugowania tylko na jednej maszynie, a na pozostałych zwiększyć poziom logowania np. na standardowe wyjście i przeglądać logi już po fakcie.

Breakpoint warunkowy [conditional breakpoint]Większość debuggerów daje możliwość określenia specjalnych dodatkowych warunków dla breakpointów. Jest to niezwykle przydatne, jeżeli dany fragment kodu jest wykonywany wiele razy, a my chcemy złapać wywołanie aplikacji tylko w jednym przypadku.

Dla przykładu z obrazka, zamiast klikać 300 razy next, next... można ustawić właśnie takie warunki i poczekać, aż debugger zrobi resztę. W ten sam sposób można również np.

W tym artykule wyjaśniono, jak rozpocząć debugowanie Windows przy użyciu narzędzia WinDbg i innych narzędzi do debugowania.

1. Zainstaluj usługę WinDbg, aby rozpocząć debugowanie Windows aplikacji i sterowników.

2. Zazwyczaj do debugowania są używane dwa oddzielne systemy komputerowe, ponieważ proces często wstrzymuje wykonywanie instrukcji na procesorze. W niektórych sytuacjach można użyć maszyny wirtualnej jako drugiego systemu. Na przykład komputer wirtualny może działać na tym samym komputerze co kod, który należy debugować. Jeśli jednak kod komunikuje się ze sprzętem niskiego poziomu, użycie komputera wirtualnego może nie być najlepszym rozwiązaniem.

3. System operacyjny i programy uprzywilejowane działają w trybie jądra . Kod trybu jądra ma uprawnienia dostępu do dowolnej części systemu i nie jest ograniczony jak kod trybu użytkownika. Kod trybu jądra może uzyskać dostęp do dowolnej części dowolnego innego procesu uruchomionego w trybie użytkownika lub w trybie jądra. Aplikacje i podsystemy na komputerze działają w trybie użytkownika. Procesy uruchamiane w trybie użytkownika robią to we własnych wirtualnych przestrzeniach adresowych. Są one ograniczone do uzyskiwania bezpośredniego dostępu do wielu części systemu, w tym sprzętu systemowego, pamięci, która nie jest przydzielona do ich użycia, oraz innych części systemu, które mogą naruszyć integralność systemu.

Jeśli twoim celem jest debugowanie sterownika, ustal, czy sterownik jest sterownikiem trybu jądra lub sterownikiem trybu użytkownika. Sterowniki Windows Driver Model (WDM) oraz Kernel-Mode Driver Framework (KMDF) są obydwa sterownikami działającymi w trybie jądra. W przypadku niektórych problemów trudno jest określić tryb wykonywany przez kod. W takim przypadku może być konieczne wybranie jednego trybu i sprawdzenie, jakie informacje są dostępne w tym trybie. W zależności od trybu debugowania może być konieczne skonfigurowanie i użycie debugerów na różne sposoby.

4. Debuger WinDbg działa dobrze w większości sytuacji, ale czasami warto użyć innego debugera, takiego jak debugery konsoli na potrzeby automatyzacji lub Visual Studio.

5. Zazwyczaj łączy się systemy docelowe i systemy hostów przy użyciu sieci Ethernet. Jeśli wykonujesz wczesne prace uruchomieniowe lub nie masz połączenia Ethernet na urządzeniu, dostępne są inne opcje połączeń sieciowych. Niezależnie od tego, czy potrzebujesz debugera 32-bitowego, czy 64-bitowego, zależy od wersji Windows działającej w systemach docelowych i hostów oraz czy debugujesz kod 32-bitowy, czy 64-bitowy.

7. Aby użyć wszystkich zaawansowanych funkcji zapewnianych przez usługę WinDbg, należy załadować odpowiednie symbole. Jeśli symbole nie są prawidłowo konfigurowane, podczas próby użycia funkcji, która zależy od symboli, otrzymujesz komunikaty wskazujące, że symbole nie są dostępne.

8. Jeśli twoim celem jest debugowanie własnego kodu źródłowego, musisz skonfigurować ścieżkę do kodu źródłowego.

9. W sekcji Operacji debugera tej dokumentacji opisano operację debugera dla różnych zadań.

10. standardowe techniki debugowania mają zastosowanie do większości scenariuszy debugowania, a przykłady obejmują ustawianie punktów przerwania, inspekcję stosu wywołań i znalezienie przecieku pamięci. wyspecjalizowane techniki debugowania mają zastosowanie do określonych technologii lub typów kodu.

11. Użyj różnych poleceń debugowania podczas pracy w debugerze.

12. Używanie wielu rozszerzeń debugowania do analizowania struktur danych specyficznych dla domeny. Aby uzyskać więcej informacji, zobacz Wyspecjalizowane rozszerzenia.

W tej dokumentacji założono, że masz pewną wiedzę na temat podstawowych Windows wewnętrznych. Aby dowiedzieć się więcej na temat Windows internals, w tym użycia pamięci, kontekstu, wątków i procesów, przejrzyj zasoby, takie jak Windows Internals autorstwa Pavela Yosifovicha, Marka E. Russinovicha, Davida A.

14. podstawowych narzędzi. KD - Kernel debugger. CDB - Command-line debugger. NTSD - NT debugger. do debugowania aplikacji użytkownika. Windbg - poł±czenie KD oraz NTSD wykorzystuj±c graficzny UI.

w trybie użytkownika jak i w trybie j±dra. uczynić, jest podanie ¶cieżki do plików symboli. Jak już wspomniano, WinDbg udostępnia kilka opcji debugowania programu.

debugowania. na jednym komputerze, przy wykorzystaniu drugiego komputera. maszynę. WinDbg na serwerze. protokołów. oraz poleceń, które wydaj±. Zakończenie klienta następuje po wybraniu File | Exit. Możliwe jest ustawienie WinDbg jako domy¶lnego debugera JIT. otrzymuje dwie szanse obsłużenia tego wyj±tku. samodzielnie wyj±tku ("second-chance exception"). na podgl±d zapisu wyj±tku i stosu wywołań aplikacji.

z dokumentacji Debugging Tools for Windows. Zawiera kod Ľródłowy programu. tabelach, sporz±dzonych na podstawie Ľródeł materiałów do projektu. Ustawia punkt kontrolny z wyprzedzeniem. zgodnie z rozpoznanym typem. Wy¶wietla listę kodu programu w asemblerze. Wy¶wietla aktualne wartości rejestrów procesora. nieprzewidzianego zakończenia. dump przez użycie polecenia .dump. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Instrukcja spod "0x%08lx" odwołuje się do pamięci pod adresem "0x%08lx". WARNING: Stack unwind information not available.

tags: #tryb #debugowania #windows #7

Popularne posty:

• Honor 7 nie jest wykrywany przez Windows 10: kroki naprawcze po podłączeniu
• Linux: jak wyłączyć czas amerykański i przywrócić poprawną strefę czasową – instrukcja krok po kroku
• Jak zainstalować Ubuntu od podstaw — przewodnik krok po kroku
• Kroki naprawy problemu: Ethernet nie ma poprawnej konfiguracji IP w Windows 10
• Jak połączyć Analytics z Google Ads: uprawnienia administratora i pełna konfiguracja