Ladiaci program je druhá vec po kompilátore na vytváranie programov. Mnohí z tých, ktorí píšu počítačové programy a používajú debugger, si však nie sú vedomí zásad a mechanizmov jeho práce.
Je ťažké byť debuggerom...
Vzhľadom na skutočnosť, že programátori používajú debugger vo dne v noci, najmä keď vstúpia do režimu hlbokého ladenia, stojí za to povedať, že ak by debugger nebol program, ale kus hardvéru, pravdepodobne by sa prehrial a pokazil. Pretože ani kompilátor nemá toľko práce, koľko dostane debugger.
Samozrejme, keďže teraz existuje veľa rôznych programovacích jazykov, ladiace programy pre každý z nich sú odlišné. A samozrejme, pre rôzne kategórie týchto jazykov existujú rozdiely v práci debuggerov: napríklad debugger pre interpretované programy Ruby bude fungovať inak ako pre Javu kompilovanú do bajtového kódu a debugger pre Javu zasa, bude mať rozdiely od debuggera Visual C ++.
Budem hovoriť o ladení pre platformu Windows. Po pochopení princípov debuggerov pre to bude možné porozumieť debuggerom pre systémy POSIX aj debuggerom, ktoré nepracujú na úrovni operačného systému, ale na úrovni virtuálneho počítača alebo nejakého druhu tlmočníka.
Debuggery pre Windows: Dva druhy
Existujú dva zásadne odlišné druhy ladiacich programov pre Windows. Myslím, že každý bol prvý, s kým sa stretol, keď programoval v Delphi (neprogramoval v ňom? Je ťažké tomu uveriť. Na čo ste programovali v školských a juniorských rokoch?). Jedná sa o vlastné ladiace programy aplikácií. Je ich veľa a existujú samostatne a (mimochodom najmä často) ako súčasť integrovaných prostredí vývoja aplikácií. Medzi debuggermi distribuovanými ako samostatné softvérové produkty sa tradične odlišuje OllyDbg, o ktorom som kedysi písal v „Computer News“.
Druhým typom debuggera je ladiaci program jadra operačného systému. Nachádzajú sa a používajú menej často a výrazne sa líšia svojim dizajnom od debuggerov pre vlastné aplikácie. Najslávnejším a zároveň najlepším z debuggerov jadra je SoftIce. Možno ste o ňom nielen počuli, ale dokonca ho aj používali.
Keďže práca každého z dvoch typov debuggerov má svoje špecifiká, o každom z nich vám poviem viac.
Vlastný debugger aplikácií
Ladiaci program vlastných aplikácií je jednoduchší, pretože operačný systém preberá najšpinavšiu a najšpinavšiu prácu. Windows má špeciálne programovacie rozhrania na ladenie aplikácií na úrovni používateľa – nazývajú sa Windows Debugging API. Sú to ladiace API, ktoré používajú všetky debuggery zabudované do populárnych Windows IDE.
Aby sa ladenie začalo, musí debugger spustiť ladený proces špeciálnym spôsobom, aby systém vedel, že tento proces bude prebiehať ladením. Potom sa začne cyklus ladenia: program sa vykonáva, kým nenastane určitá udalosť, ktorá sa nazýva udalosť ladenia alebo udalosť ladenia. Spustí sa ladiaca slučka v samostatnom vlákne, aby sa ladiaci program nezavesil.
Ale toto je len začiatok. Pretože to najzaujímavejšie na práci debuggera začína už vtedy, keď nastala udalosť ladenia. Koniec koncov, čo je vlastne úlohou debuggera? Pomôcť programátorovi lokalizovať chybu na konkrétnu funkciu, konkrétnu operáciu alebo konkrétnu premennú. V tejto náročnej úlohe môže debuggerovi pomôcť aj operačný systém.
Takže došlo k udalosti ladenia a potom musíme nejako zistiť, ako to súvisí s textom programu. To je možné iba vtedy, ak samotný program obsahuje špeciálne informácie o ladení - tabuľku symbolov ladenia. Obsahuje informácie o zhode medzi adresami a názvami funkcií, typmi údajov, číslami kódových riadkov. Práve vďaka nim je možné ladenie, ktoré pozná každý programátor Windows. Tabuľky symbolov majú rôzne formáty, a preto nie je vždy možné ladiť program zostavený kompilátorom jedného dodávateľa pomocou debuggera od iného dodávateľa. Najbežnejší formát však stále možno špecifikovať - ide o PDB (Program Database) a vyvinul ho, samozrejme, Microsoft.
Ak je teda tabuľka symbolov ladenia vo formáte PDB, môžete použiť špeciálny nástroj od spoločnosti Microsoft - symbolický ladiaci procesor. Kedysi to bolo súčasťou jadra systému a nazývalo sa Imagehlp.dll, ale už bolo dávno oddelené do samostatnej knižnice. Znakový procesor vám umožňuje nájsť najbližšiu otvorenú funkciu alebo globálnu premennú na danej adrese, ako aj číslo riadku a názov zdrojového súboru, v ktorom sa tento riadok nachádza. Podporované sú aj inverzné operácie, napríklad hľadanie adresy funkcie podľa jej názvu.
Toto, samozrejme, nie je všetka práca, ktorú vykonáva ladiaci program vlastných aplikácií. Napríklad pri ladení viacvláknových aplikácií existuje veľa veľmi jemných problémov súvisiacich s interakciou vlákien. Dokonca aj pri ladení relatívne jednoduchých vecí, ako sú služby, existujú nuansy.
Ale teraz sa nebudeme zaoberať nuansami - na konci článku vám poviem, kde si o nich môžete prečítať. Zatiaľ sa pozrime na ladiace programy jadra.
Debugger jadra
Debuggery jadra sú oveľa zložitejšie programy ako debuggery vlastných aplikácií a predpokladám, že je pochopiteľné prečo: chýba im pomocník operačného systému. Ona je v tomto prípade ich klientom, pretože je to ona, koho v konečnom dôsledku musia odladiť.
Väčšina ladiacich programov jadra vyžaduje na spustenie dva počítače spojené káblom nulového modemu. Nulový modem je spôsob, ako pripojiť dva počítače priamo pomocou kábla cez ich porty COM alebo LTP. Druhý počítač je potrebný, pretože časť debuggera sediaca na prvom (tá, kde je nainštalovaný ladený systém) má obmedzený prístup k hardvéru, a preto všetky výstupy dát idú cez nulový modem do druhého počítača.
V moderných procesoroch architektúry Intel x86 sú špeciálne registre ladenia (v starej 368 aj v novších modeloch procesorov je ich už len osem, označujú sa ako DR0-DR7). Tieto registre umožňujú nastavenie debuggeru kontrolné body na čítanie a zápis pamäte, ako aj na I/O porty. Vo všeobecnosti všetko vyzerá presne takto a nemyslím si, že teraz stojí za to podrobne popisovať, za čo je zodpovedný každý z registrov ladenia, aké prerušenia sa používajú na implementáciu bodov prerušenia a poskytovanie ďalších podobných informácií. Radšej by som hovoril o konkrétnych existujúcich ladiacich programoch jadra pre Windows.
No, v prvom rade je to debugger zabudovaný do samotného jadra operačného systému. Je k dispozícii vo všetkých operačných systémoch NT počnúc Windows 2000. Je súčasťou súboru NTOSKRNL.EXE a dá sa povoliť nastavením voľby "/ Debug" pre operačný systém v BOOT.INI. Tento debugger potrebuje pripojenie nulovým modemom a druhý počítač s rovnakým operačným systémom.
Existuje ďalší debugger jadra od spoločnosti Microsoft - WinDBG. Presne povedané, nejde o ladiaci program jadra, ale o hybridný debugger, ktorý možno použiť aj na ladenie aplikácií na úrovni používateľa. Na rozdiel od debuggeru zabudovaného v jadre má grafický shell, a preto je jeho použitie jednoduchšie. Tento debugger podporuje aj špeciálne rozšírenia, ktoré sa môžu hodiť pri niektorých úlohách ladenia. Na ladenie jadra sú však potrebné aj dva počítače.
Existuje však ladiaci program jadra, ktorý dokáže ladiť na jednom počítači. Toto je SoftIce. SoftIce zároveň dokáže ladiť aj aplikačné programy. Použitie tohto ladiaceho programu pre užívateľské programy je odôvodnené napríklad v prípade ladenia systémov v reálnom čase viazaných na systémový časovač. Ak ladíte obyčajným debuggerom, výsledok môže byť nesprávny, aj keď program beží správne a SoftIce zastaví program aj časovač. To je užitočné pri ladení aplikácií s viacerými vláknami. Okrem toho má SoftIce veľmi, veľmi dobre vyvinuté prostriedky na zobrazovanie informácií o všetkých vláknach v systéme, o synchronizácii vlákien pre viacvláknové aplikácie, informácie o handle "ach... Jedinou nevýhodou tohto debuggera je jeho zložitosť pre aplikačného programátora. Ale z kernel debuggerov je to najjednoduchšie a najefektívnejšie.
Pre najzvedavejších
Teraz, samozrejme, hovoriť o debuggeroch pre aplikácie Windows nie je také relevantné ako pred desiatimi rokmi. O internet sa začal zaujímať celý svet a hlavnými užívateľmi SoftIce boli crackeri, neúnavní pracovníci v oblasti pirátstva. To však nie je také zlé. Komunikácia so SoftIce nepochybne rozvíja človeka, čo sa týka vedomostí o počítači, aj keď, samozrejme, ak komunikujete iba s debuggermi a nekomunikujete so skutočnými ľuďmi, nejaké vedľajšie účinky sú možné.. No, myslím, že o tom už každý vie.
Ladiace programy sú niektoré z najvýraznejších typov softvéru, ale z hľadiska vývoja sú aj ladiace programy na úrovni používateľa pomerne zložité. Ale napriek tomu, ak máte chuť a čas vyvinúť vlastný debugger, vaše znalosti operačných systémov a programovania sa výrazne zvýšia, čo znamená, že sa zvýši aj šanca na dobre platenú prácu.
Takže, ak si chcete vytvoriť svoj vlastný debugger, mali by ste si najprv prečítať materiály na túto tému. Podľa môjho názoru je najlepším miestom, kde začať, kniha Johna Robbinsa Debugging Windows Applications. Je už starý, vydaný v roku 2001, ale informácie v ňom obsiahnuté sú aktuálne aj teraz, keďže majú všeobecný, ba až trochu zásadný charakter. Táto kniha obsahuje príklady písania debuggerov pre Windows a je tiež užitočná, ak programujete v C ++ a chcete lepšie pochopiť spracovanie výnimiek. V skutočnosti som z tejto knihy získal informácie o debuggeroch uvedených v článku. Ak nemôžete nájsť túto knihu (nakoniec je už dosť stará), existuje niekoľko adries, ktoré sa vám môžu hodiť. Prvý z nich je takýto: www.xakep.ru/post/19158/default.asp. Tento článok z magazínu „Hacker“ hovorí o debuggeroch jadra trochu viac ako ja a navyše obsahuje kód jednoduchého debuggera. A na kalashnikoff.ru/Assembler/issues/016.htm sa môžete naučiť, ako napísať debugger DOS. Ale, samozrejme, najlepšie je prečítať si MSDN a po ceste nájsť open source debugger, aby ste na to prišli. A samozrejme, ak sa pustíte do písania debuggera, potom úspech v tejto ťažkej úlohe!
Táto séria článkov sa objavila z dvoch dôvodov. V prvom rade sa mi páči práca s projektom HackSysExtremeVulnerableDriver... Po druhé, mám veľa prianí na zdôraznenie tejto témy.
Všetok kód použitý pri písaní tejto série je v mojom úložisku.
V tejto sérii článkov sa pozrieme na písanie exploitov na úrovni jadra v systéme Windows. Je dôležité si uvedomiť, že sa budeme zaoberať známymi chybami zabezpečenia a nie je potrebné reverzné inžinierstvo (aspoň pre vodiča).
Po prečítaní všetkých článkov sa očakáva, že budete oboznámení so všetkými najbežnejšími triedami zraniteľností a metódami využívania, ako aj budete schopní preniesť exploity z architektúry x86 na architektúru x64 (ak je to možné) a zoznámite sa s nové metódy ochrany v systéme Windows 10.
Schéma ladenia jadra
Na rozdiel od ladenia na úrovni používateľa, keď je pozastavené vykonávanie jednotlivého procesu, na úrovni jadra je zapojený celý systém a túto metódu nemôžeme použiť. Preto potrebujete samostatný ladiaci stroj, ktorý dokáže komunikovať so systémom, kde sa ladí jadro, prezerať si štruktúru pamäte a jadra a zachytávať pády systému.
Dodatočný materiál na štúdium:
Zneužívanie zraniteľností jadra
Tento proces je oveľa zábavnejší ako využívanie používateľskej úrovne J.
Hlavným cieľom je dosiahnuť privilegované spustenie v kontexte jadra. A potom už všetko závisí od našej fantázie, od hostiny s domácim pivom až po zavedenie štátom podporovaného malvéru.
Vo všeobecnosti je našou úlohou získať shell so systémovými oprávneniami.
Témy pre túto sériu
- Časť 1: Nastavenie pracovného prostredia
- Konfigurácia troch virtuálnych počítačov a systému, ktorý bude fungovať ako debugger.
- Konfigurácia WinDBG Debugger.
- Časť 2: Užitočné zaťaženia
- Preskúmanie najbežnejších užitočných zaťažení. Nasledujúce časti sa budú zaoberať konkrétnymi chybami zabezpečenia a podľa potreby poskytnú odkazy na tento článok.
- Zvyšné časti.
- Zohľadnenie slabých miest.
Životný cyklus vývoja zneužívania na úrovni jadra
- Nájdenie zraniteľnosti... Tejto téme sa táto séria nebude venovať, keďže už presne vieme, kde sú diery.
- Zachytenie vlákna popravy... Niektoré zraniteľnosti zahŕňajú spustenie kódu, niektoré majú ďalšie požiadavky.
- Rozšírenie privilégií... Hlavným cieľom je získať shell so systémovými oprávneniami.
- Obnovenie toku vykonávania... Nespočetné výnimky na úrovni jadra spôsobujú pád systému. Ak sa nechystáte napísať exploit DoS, túto skutočnosť treba zvážiť.
Typy cieľových systémov
Budeme pracovať so zraniteľnosťami v nasledujúcich systémoch (konkrétna verzia nie je dôležitá):
- Win7 x86 VM
- Win7 x64 VM
- Win10 x64 VM
Začnime architektúrou x86 a potom prenesieme exploit na systém Win7 x64. Niektoré exploity nebudú fungovať na počítačoch Win10 kvôli novým ochranám. V takom prípade buď zmeníme logiku exploitu, alebo použijeme úplne iný prístup.
Použitý softvér:
- Hypervisor (veľa možností).
- Windows 7 x86 VM
- Windows 7 x64 VM
- Windows 10 x64 VM
Nastavenie systémov na ladenie
Ladiace systémy, s ktorými budeme interagovať, sú navrhnuté tak, aby načítali zraniteľný ovládač. Tieto počítače budú často padať, pretože väčšina výnimiek jadra prispieva k tomuto druhu správania. Pre tieto systémy musíte prideliť dostatok pamäte RAM.
Na každom počítači, ktorý bude ladený, musíte urobiť nasledovné:
- V adresári VirtualKD spustite target \ vminstall.exe. Bude pridaný nový bootovací záznam a bude ladený a automatické pripojenie na server VirtualKD nainštalovaný v systéme, ktorý funguje ako debugger.
V prípade Windows 10 VM je potrebné povoliť režim testovacieho podpisovania, ktorý umožňuje načítanie nepodpísaných vodičov do jadra.
Po spustení testovania bcdedit / set na príkaz a reštarte sa na pracovnej ploche zobrazí „Testovací režim“.
Stručný popis modulu HEVD
Procedúra DriverEntry je štartovacia procedúra pre každého vodiča:
NTSTATUS DriverEntry (IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) (
UINT32 i = 0;
PDEVICE_OBJECT DeviceObject = NULL;
Stav NTSTATUS = STATUS_UNSUCCESSFUL;
UNICODE_STRING Názov zariadenia, DosDeviceName = (0);
UNREFERENCED_PARAMETER (Cesta registra);
PAGED_CODE ();
RtlInitUnicodeString (& DeviceName, L "\\ Device \\ HackSysExtremeVulnerableDriver");
RtlInitUnicodeString (& DosDeviceName, L "\\ DosDevices \\ HackSysExtremeVulnerableDriver");
// Vytvorte zariadenie
Stav = IoCreateDevice (DriverObject,
0,
& Názov zariadenia,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
FALSE,
& DeviceObject);
- Tento postup obsahuje volanie funkcie IoCreateDevice obsahujúce názov ovládača, ktorý budeme používať počas komunikácie.
- Požadované štruktúry a ukazovatele funkcií budú pridané do DriverObject.
- Pre nás je dôležitý funkčný ukazovateľ spojený s procedúrou DriverObject-> MajorFunction, ktorý je zodpovedný za obsluhu IOCTL (I/O Control; I/O control);
- HEVD nazýva túto funkciu IrpDeviceIoCtlHandler, čo je veľký podmienený výraz s mnohými vetvami pre každé IOCTL. Každá zraniteľnosť má jedinečný IOCTL.
Príklad: HACKSYS_EVD_IOCTL_STACK_OVERFLOW je IOCTL, ktorý sa používa na aktiváciu zraniteľnosti pretečenia zásobníka.
Týmto sa končí prvá časť. V nasledujúcom článku si povieme niečo o užitočnom zaťažení. Zapnuté tento moment k dispozícii je iba užitočné zaťaženie na krádež tokenov, ktoré sa použije v tretej časti.
P.S. Chápem, že existuje veľa jemností a problémov, s ktorými sa môžete stretnúť. Keďže sa tento cyklus zameriava na vývoj exploitov, všetky súvisiace problémy budete musieť vyriešiť sami. Môžete sa však opýtať na všetky otázky, ktoré sa objavia v komentároch.
Úvod
1. Typy ladiacich programov Windows
2. Debuggery používateľského režimu
3. Debuggery v režime jadra
3.1 Debugger WDEB386
3.2 debugger I386KD
3.3 Vyhrajte DBG Debugger
3.4 SoftICE Debugger
4. Všeobecná ladiaca otázka
5. Automatické spúšťanie aplikácií v debuggeri
5.1 Skratky prerušenia
Záver
Literatúra
Úvod
Najťažšou časťou procesu ladenia je naučiť sa, ako fungujú softvérové nástroje. Len ak pochopíte možnosti a obmedzenia nástrojov, môžete z nich vyťažiť viac a stráviť menej času ladením. Debuggery sú vo všeobecnosti mimoriadne užitočné, ale môžu viesť k pomerne jemným problémom, ktoré zanechajú programátora zmäteným. Táto kapitola vám ukáže, čo je debugger a ako fungujú rôzne debuggery v operačných systémoch Win32 (32-bitové operačné systémy Microsoft Windows).
V tomto prípade sa zameriame na tie špeciálne vlastnosti debuggerov vo všeobecnosti, ktoré sú povolené, keď je programový proces vykonávaný pod ich kontrolou. Vysvetľuje tiež, ako využiť niektoré vlastnosti 32-bitových operačných systémov Windows na uľahčenie ladenia. Predstavené budú dva vlastné debuggery, ktorých zdrojový kód nájdete na sprievodnom CD. Prvý z nich (MinDBG) má dostatok schopností na to, aby sa dal nazvať debuggerom. Druhý (WDBG) je príkladom ladiaceho programu Microsoft Windows, ktorý robí takmer všetko, čo robí skutočný systémový debugger, vrátane manipulácie so tabuľkami symbolov, manipulácie s bodmi prerušenia, generovania kódu demontéra a koordinácie s grafickým používateľským rozhraním (GUI). V diskusii o WDBG vám ukážeme, ako fungujú body prerušenia a rozoberieme, čo sú rôzne súbory symbolov.
Predtým, ako prejdeme k hlavnému materiálu tejto kapitoly, definujeme dva štandardné pojmy, ktoré sa budú často používať v tejto knihe: hlavný (alebo základný) debugger a vedľajší debugger (debuggee). Zjednodušene povedané, hlavný debugger je proces, ktorý môže ladiť iný proces, zatiaľ čo vedľajší debugger je proces, ktorý beží pod hlavným ladiacim programom. V niektorých operačných systémoch sa hlavný ladiaci program nazýva nadradený proces a podriadený ladiaci program sa nazýva potomok.
Debugger (ladiaci program, anglický debugger z chyby) - počítačový program, určený na vyhľadávanie chýb v iných programoch, jadrách operačných systémov, SQL dotazoch a iných typoch kódu. Ladiaci nástroj vám umožňuje sledovať, monitorovať, nastavovať alebo meniť hodnoty premenných počas vykonávania kódu, nastavovať a odstraňovať body prerušenia alebo podmienky zastavenia atď.
Väčšina vývojárov viac pozná ladiace programy v užívateľskom režime. Nie je prekvapením, že tento režim ladenia je určený na ladenie aplikácií v používateľskom režime. Hlavným príkladom ladiaceho nástroja v používateľskom režime je ladiaci nástroj Microsoft Visual C++. Ladiace programy v režime jadra, ako naznačuje ich názov, sú ladiace programy, ktoré vám umožňujú ladiť jadro operačného systému. Používajú ich predovšetkým tí, ktorí píšu (a samozrejme ladia) ovládače zariadení.
2. Debuggery užívateľského režimu
Ladiace programy v používateľskom režime sú navrhnuté tak, aby ladili ľubovoľnú aplikáciu bežiacu v používateľskom režime, vrátane akýchkoľvek programov GUI, ako aj niektorých iných ako pravidelné aplikácie ako služby Windows 2000. Vo všeobecnosti tieto typy debuggerov podporujú grafické používateľské rozhranie (GUI1). Hlavnou črtou takýchto debuggerov je, že používajú rozhranie Win32 Debug Application Programming Interface (Debug API). Pretože operačný systém označí podriadený ladiaci program ako „bežiaci v špeciálnom režime“, môžete použiť IsDebuggerPresent API na určenie, či váš proces beží pod ladiacim programom.
Pri odosielaní ladiaceho API Win32 platí konvencia, že akonáhle proces beží pod ladiacim API (a teda z neho robí podriadený proces), hlavný ladiaci program sa nemôže od procesu odpojiť. Tento symbiotický vzťah znamená, že ak sa ukončí hlavný debugger, ukončí sa aj vedľajší debugger. Hlavný debugger je obmedzený na ladenie iba podradeného debuggeru a všetkých procesov, ktoré sa vyskytnú (ak hlavný debugger podporuje podradené procesy).
GUI – grafické používateľské rozhranie. - Za.
Pre interpretované jazyky a run-time systémy, ktoré využívajú prístup virtuálneho stroja, samotné virtuálne stroje poskytujú kompletné ladiace prostredie a nepoužívajú Win32 debug API. Niektoré príklady týchto typov prostredí sú: virtuálne stroje Java (JVM) od spoločnosti Microsoft alebo Sun, skriptovacie prostredie pre webové aplikácie od spoločnosti Microsoft a interpret p-kódu v jazyku Microsoft Visual Basic.
operačný systém jadra ladiaceho programu
K ladeniu vo Visual Basicu sa dostaneme v kapitole 7, ale uvedomte si, že rozhranie Visual Basic p-code nie je zdokumentované. Nebudeme sa venovať Jave a rozhraniam na ladenie skriptov, tieto témy presahujú rámec tejto knihy. Ďalšie informácie o ladení a profilovaní Microsoft JVM nájdete v časti „Ladenie a profilovanie aplikácií Java“ na MSDN. Sada takýchto rozhraní je veľmi bohatá a pestrá a umožňuje úplne ovládať prevádzku JVM. Informácie o písaní ladiaceho nástroja skriptov nájdete v téme MSDN "Aktívne objekty rozhrania API na ladenie skriptov". Podobne ako JVM, aj objekty ladenia skriptov poskytujú bohaté rozhranie pre skriptovací prístup a dokumentáciu.
Prekvapivo veľký počet programov používa Win32 Debug API. Patria sem: ladiaci program Visual C++, ktorý je podrobne popísaný v kapitolách 5 a 6; Windows Debugger (WinDBG), o ktorom sa hovorí v ďalšej časti (o ladiacom nástroji v režime jadra); softvér BoundsChecker od spoločnosti Compuware NuMega; Program platformy SDK HeapWalker; Platforma SDK závisí od programu; Debuggery Borland Delphi a C++ Builder a NT Symbolic Debugger (NTSD). Som si istý, že ich je oveľa viac.
3. Debuggery v režime jadra
Debuggery v režime jadra sú umiestnené medzi CPU a operačným systémom. To znamená, že keď zastavíte ladiaci program v režime jadra, operačný systém sa tiež úplne zastaví. Nie je ťažké si uvedomiť, že náhle zastavenie operačného systému je užitočné, keď pracujete s problémami s časovačom a načasovaním. Avšak s výnimkou jedného debuggera, o ktorom sa bude diskutovať nižšie (v časti SoftlCE Debugger tejto kapitoly), nemôžete ladiť kód používateľského režimu pomocou ladiacich programov v režime jadra.
Debuggerov v režime jadra nie je veľa. Niektoré z nich sú: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG a SoftlCE. Každý z týchto debuggerov je stručne popísaný v nasledujúcich častiach.
3.1 Debugger WDEB386
WDEB386 je ladiaci program režimu jadro systému Windows 98, distribuovaný s Platform SDK. Tento debugger je užitočný iba pre vývojárov, ktorí píšu virtuálne ovládače. Zariadenia so systémom Windows 98 (VxD). Ako väčšina ladiacich programov v režime jadra pre operačné systémy Windows, aj ladiaci program WDEB386 vyžaduje na spustenie dva počítače a kábel nulového modemu. Sú potrebné dva stroje, pretože časť debuggera, ktorá beží na cieľovom počítači, má obmedzený prístup k svojmu hardvéru, takže odosiela svoj výstup a prijíma príkazy z druhého počítača.
Ladiaci nástroj WDEB386 má zaujímavý príbeh... Začalo to ako interný nástroj na pozadí spoločnosti Microsoft v ére Windows 3.0. Bolo ťažké ho používať a chýbala mu dostatočná podpora pre ladenie zdrojového kódu a ďalšie pekné funkcie, ktorými nás ladiace programy Visual C++ a Visual Basic rozmaznali.
Bodové príkazy sú najdôležitejšou funkciou WDEB386. Prerušenie INT 41 možno použiť na rozšírenie WDEB386 o pridávanie príkazov. Táto rozšíriteľnosť umožňuje autorom ovládačov VxD vytvárať vlastné ladiace príkazy, ktoré im poskytujú voľný prístup k informáciám v ich virtuálnych zariadeniach. Ladiaca verzia systému Windows 98 podporuje mnoho príkazov DOT, ktoré vám umožňujú sledovať presný stav operačného systému v ktoromkoľvek bode procesu ladenia.
3.2 debugger I386KD
Windows 2000 sa líši od Windows 98 v tom, že skutočná časť ladiaceho nástroja v režime jadra je súčasťou NTOSKRNL. EXE - súbor hlavného operačného jadra systémy Windows 2000. Tento debugger je dostupný vo voľnej (vydanie) aj overenej (ladenie) konfigurácii operačného systému. Ak chcete povoliť ladenie v režime jadra, nastavte parameter zavádzača / DEBUG na hodnotu BOOT. INI a voliteľne možnosť zavádzača / DEBUGPORT, ak chcete nastaviť komunikačný port ladiaceho nástroja jadra na niečo iné ako predvolené (COM1). I386KD beží na vlastnom počítači a komunikuje s ním Stroj so systémom Windows 2000 cez nulový modemový kábel.
Debugger v režime jadra NTOSKRNL. EXE robí iba toľko, aby ovládal CPU, aby bolo možné odladiť operačný systém. Väčšina ladiacich prác - manipulácia so symbolmi, rozšírené zarážky a demontáž - sa vykonáva na strane 1386KD. Súprava ovládačov zariadenia Windows NT 4 (DDK) naraz dokumentovala protokol používaný v kábloch nulového modemu. Microsoft to však už nedokumentuje.
Sila 1386 kD je evidentná, keď sa pozriete na všetky príkazy, ktoré ponúka na prístup k internému Stav systému Windows 2000. Vedieť, ako fungujú ovládače zariadení v systéme Windows 2000, pomôže programátorovi sledovať výstup mnohých príkazov. Napriek všetkému, čo je v ňom, i386KD sa takmer nikdy nepoužíva, pretože je to konzolová aplikácia, ktorú je veľmi únavné používať na ladenie na úrovni zdroja.
3.3 Vyhrajte DBG Debugger
WinDBG je debugger, ktorý sa dodáva so súpravou Platform SDK. Môžete si ho stiahnuť aj z # "897008.files / image001.gif">
Obr 1. Výstup programu GFLAGS. exe
Zoznam 4-1. Príklad zničenia haldy systému Windows 2000
void main (void)
HANDLE hHeap = HeapCreate (0, 128, 0);
// Alokácia pamäte pre 10 bajtový blok.
LPVOID pMem = HeapAlloc (hHeap, 0,10);
// Zápis 12 bajtov do 10 bajtového bloku (pretečenie haldy).
memset (pMem, OxAC,
// Pridelenie nového bloku 20 bajtov.
LPVOID pMem2 = HeapAlloc (hHeap, 0, 20);
// Zápis 1 bajtu do druhého bloku.
char * pUnder = (char *) ((DWORD) pMem2 - 1);
// Uvoľnite prvý blok. Toto volanie HeapFree bude
// spúšťa bod prerušenia v kóde haldy ladenia
// operačný systém.
HeapFree (hHeap, 0, pMem);
// Uvoľnite druhý blok. Upozorňujeme, že tento hovor nebude
// tlač chybových správ
HeapFree (hHeap, 0, pMem2);
// Uvoľnite fiktívny blok. Upozorňujeme, že tento hovor nebude
// tlač chybových správ
Ak začiarknete rovnaké políčka ako na obrázku 4.1 a zopakujete vykonanie HEAPER. EXE, získate nasledujúci podrobnejší výstup:
PAGEHEAP: proces 0x490 vytvoril haldu ladenia 00430000
(vlajky 0xl, 50, 25, 0, 0): proces 0x490 vytvoril haldu ladenia 00CF0000
(príznaky Oxl, 50, 25, 0, - 0): proces 0x490 vytvorená halda ladenia 01600000
(príznaky Oxl, 50, 25, 0, 0): Zistilo sa poškodenie výplne chvosta: pri veľkosti 0x01606FF0veľkosť 0x0000000Veľkosť 0x00000010 pri Ox01606FFA: Pokus o referenčný blok, ktorý nie je pridelený
Obsah zoznamu vysvetľuje názvy príznakov nastavených panelom Globálne príznaky.
Diskusia o programe GFLAGS. EXE, chcem poukázať na jednu veľmi užitočnú možnosť - Show Loader Snaps. Ak začiarknete toto políčko a spustíte aplikáciu, uvidíte, čo sa nazýva snímka aplikácie, ktorá ukazuje, kde Windows 2000 načítava knižnice DLL a ako začína organizovať importy. Ak potrebujete presne vidieť, čo robí bootloader systému Windows 2000 pri načítavaní aplikácie (najmä v prípade, že sa v nej nájde problém), potom môže byť povolenie tejto možnosti veľmi užitočným opatrením. Ďalšie informácie o snímkach zavádzača nájdete v stĺpci Mata Pietreca „Under the Hood“ v časopise Microsoft Systems Journal zo septembra 1999.
5. Automatické spúšťanie aplikácií v debuggeri
Najťažšie laditeľné typy aplikácií sú tie, ktoré sú spustené iným procesom. Táto kategória je napadnutá služby Windows 2000 a out-of-process COM servery (COM out-of-process servers). V mnohých prípadoch môžete použiť DebugBreak API na vynútenie pripojenia ladiaceho programu k procesu. V dvoch prípadoch však táto funkcia nebude fungovať. Po prvé, niekedy nefunguje so službami systému Windows 2000. Ak potrebujete odladiť spustenie služby, zavolaním DebugBreak sa pripojí ladiaci nástroj, ale v čase, keď sa spustí ladiaci nástroj, môže vypršať časový limit služby a systém Windows 2000 ju zastaví . Po druhé, DebugBreak nebude fungovať, keď potrebujete ladiť server COM mimo procesu. Ak zavoláte DebugBreak, obslužná rutina chýb COM zachytí výnimku bodu prerušenia a ukončí server COM. Našťastie vám Windows 2000 umožňuje určiť, že sa má aplikácia spustiť v debuggeri. Táto vlastnosť vám umožňuje spustiť ladenie hneď od prvého príkazu. Pred povolením tejto vlastnosti pre službu systému Windows 2000 sa však uistite, že je služba nakonfigurovaná na komunikáciu s pracovníkom. Stôl s oknami 2000.
Spustenie s vlastnosťou debugger je možné povoliť dvoma spôsobmi. Najjednoduchšie je spustiť utilitu GFLAGS. EXE a vyberte prepínač ObrázokSúbor možnosti(pozri obrázok 4.1). Po zadaní do editovateľného poľa I mágSúbornázov názvu binárneho súboru programu začiarknite políčko Debugger v skupine Obrázok Debuggermožnosti) a zadajte úplnú cestu k debuggeru do poľa úprav vedľa tohto začiarkavacieho políčka.
Zložitejší spôsob: musíte manuálne nastaviť potrebné parametre pre príslušné kľúče registra (pomocou editora RegEdit). V časti_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NTX Aktuálna verzia \ Možnosti spúšťania obrázkovej dlaždice
vytvorte podkľúč s rovnakým názvom ako názov súboru aplikácie. Napríklad, ak je názov aplikácie FOO. EXE, potom názov podkľúča databázy Registry je tiež FOO. EXE. V tejto podsekcii vytvorte nový parameter reťazca s názvom Debugger. V dialógovom okne Zmeniť parameter reťazca zadajte pomocou klávesnice úplný (spolu s cestou k adresáru) názov súboru ladiaceho programu, ktorý si vyberiete. Ak ste zadali GFLAGS. EXE a máte nainštalované nejaké globálne možnosti, budete si môcť všimnúť hodnotu malých písmen GiobaiFiag v kľúči vašej aplikácie.
Teraz, keď spustíte aplikáciu, automaticky sa načíta a spustí aj ladiaci program. možnosti príkazový riadok pre debugger možno zadať aj v parametri reťazca Debugger (za názvom programu ladiaceho nástroja). Napríklad, ak chcete použiť ladiaci program WinDBG a automaticky spustiť ladenie hneď po spustení WinDBG, musíte do dialógového okna na zmenu parametra reťazca ladiaceho programu zadať hodnotu d: \ platform sdk \ bin \ windbg. exe - g.
5.1 Skratky prerušenia
Niekedy sa musíte rýchlo dostať do debuggera. Ak ladíte konzolové aplikácie, tak stlačenia klávesov
Užitočnou funkciou Windows 2000 aj Windows NT 4 je možnosť kedykoľvek prepnúť na debugger aj v GUI aplikáciách. Pri spustení pod ladiacim programom stlačte kláves
V systéme Windows NT 4, klávesová skratka prerušenia
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ WindowsNT \ CurrentVersion \ AeDebug
nastavte parameter userDebuggerHotKey na hodnotu kľúčového kódu (VK_ *). Napríklad použiť kľúč
Záver
Preskúmali sme hlavné črty ladenia, jeho typy a typy, všeobecnú problematiku ladenia, ako aj chyby a spôsob ich odhaľovania.
Existujúce debuggery zohrávajú dôležitú úlohu pri vývoji softvéru pri hľadaní logických chýb, poskytujú širokú škálu nástrojov vrátane podpory zdrojového kódu, sledovania vykonávania aplikácií, modifikácie dynamickej pamäte atď. atď.
Literatúra
1 .. aspx? .Aspx? Id = 553022>
2. https: // ru. wikipedia.org/wiki/%D0%9E%D1%82%D0%BB%D0%B0%D0%B4%D1%87%D0%B8%D0%BA
Http: // bourabai. kz / alg / debug4. htm
4. Kostyukhin K. - LADENIE SYSTÉMOV V REÁLNOM ČASE. Prehľad
Ako spustím ladiaci program jadra?
Odpoveď majstra:
V procese vývoja softvéru je jeden veľmi dôležitý komponent – ladenie. Vo vzťahu k aplikačným programom sa vykonáva prostriedkami, ktoré bežia v užívateľskom režime a sú často integrované do IDE. Aby ste mohli ladiť napríklad ovládače, musíte spustiť ladiaci program jadra.
Musíte spustiť príkazový procesor cmd. Otvorte ponuku Štart na paneli úloh. V zobrazenom okne kliknite na položku "Spustiť ...". Zobrazí sa okno "Spustiť program". Do textového poľa zadajte cmd a kliknite na tlačidlo OK.
Teraz vytvorte zálohovanie súbor boot.ini. Najprv zistite cestu inštalácie prúdu Windows kópie pomocou príkazu: echo% SystemRoot%
Ďalej prejdite na disk s nainštalovaným operačným systémom zadaním písmen zariadenia a za nimi dvojbodkou. Pomocou príkazu cd prejdite do koreňového adresára. Teraz pomocou príkazu attrib odstráňte zo súboru boot.ini skryté, iba na čítanie a systémové atribúty. Pomocou príkazu kopírovať vytvorte zálohu a potom nastavte atribúty na miesto.
Ak chcete zobraziť aktuálny zoznam možností zavádzania, použite príkaz bootcfg / query. Prezrite si zoznam, aby ste určili, ktorý prvok sa použije na vytvorenie nových laditeľných nastavení jadra. Treba si zapamätať ID zavádzacieho záznamu.
Na vytvorenie zavádzacieho záznamu použite príkaz bootcfg / copy. Pomocou parametra / id zadajte identifikátor položky, ktorá sa má skopírovať. Pomocou parametra / d zadajte názov položky, ktorá sa má zobraziť. Teraz sa musíte vrátiť do zoznamu možností zavádzania pomocou príkazu bootcfg / query a pozrieť sa na ID pridanej položky.
Teraz musíte povoliť možnosti spustenia ladiaceho nástroja jadra v predtým vytvorenom zavádzací záznam... Ak budete ladiť na cieľovom počítači, stačí pridať možnosť / debug.
Ak chcete vykonať vzdialené ladenie s cieľovým počítačom pripojeným cez com port k hostiteľskému počítaču, potom použite možnosti / port a / baud na určenie čísla portu a prenosovej rýchlosti.
Ak sa chystáte vykonávať vzdialené ladenie pomocou kábla FireWire (rozhranie IEEE 1394), potom na aktiváciu príslušného režimu použite možnosť / dbg1394 a zadajte číslo kanála možnosť / ch.
Ak chcete overiť, že zmeny boli vykonané, otestujte zavádzacie súbory pomocou príkazu bootcfg s parametrom / query. Po vydaní príkazu exit zatvorte okno shellu.
V prípade potreby zmeňte parametre zavádzania operačného systému. Otvorte ovládací panel cez ponuku „Štart“ a už v nej otvorte položku „Systém“. V okne „Vlastnosti systému“, ktoré sa otvorí, vyberte kartu „Rozšírené“. Na tejto karte vyberte časť s názvom „Spustenie a obnovenie“ a v nej kliknite na tlačidlo „Možnosti“. V zobrazenom okne "Spustenie a obnovenie" musíte aktivovať možnosť "Zobraziť zoznam operačných systémov". Zatvorte obe dialógové okná tlačidlom "OK".
Reštartujte počítač. Vyberte spustenie s debuggerom. Prihláste sa a začnite pracovať na cieľovom počítači alebo spustite vzdialené ladenie. Použite nástroje ako WinDbg a KD.
- Autori:
Barinov S.S., Ševčenko O.G.
- rok:
- Zdroj:
Informatika a Počítačové technológie/ Materiály VI. medzinárodnej vedecko-technickej konferencie študentov, doktorandov a mladých vedcov - 23.-25. novembra 2010, Doneck, DonNTU. - 2010 .-- 448 s.
anotácia
Uvádza sa porovnávacia analýza ladenia používateľského režimu a režimu jadra vo vzťahu k operačnému systému Microsoft Windows, zdôrazňujú sa rozdiely a problémy organizácie ladenia operačného systému Microsoft Windows. Na základe získaných výsledkov sú formulované hlavné požiadavky na konštrukciu kernel-mode debuggerov v prípade núdzového a interaktívneho ladenia. Bola vykonaná analýza existujúcich riešení z hľadiska súladu s požiadavkami. Osobitná pozornosť sa venuje programu Microsoft Windows Debugger.
Hlavná časť
Ladenie je proces identifikácie a odstránenia príčin chýb v softvér... V niektorých projektoch zaberá ladenie až 50 % celkového času vývoja. Ladenie je možné výrazne zjednodušiť pomocou špecializovaných nástrojov, ktoré sa neustále zlepšujú. Hlavným takýmto nástrojom je debugger, ktorý vám umožňuje kontrolovať vykonávanie softvéru, sledovať jeho priebeh a zasahovať do neho. Nástroje na ladenie jadra používajú predovšetkým vývojári ovládačov.
Sada nástrojov na vývoj aplikačného softvéru ponúka programátorovi široké možnosti. Akékoľvek IDE zahŕňa aj možnosť ladenia bez potreby obslužných programov tretích strán. Ak hovoríme najmä o vývoji systémového softvéru a ovládačov, potom je proces vývoja vzhľadom na jeho špecifiká mimoriadne náročný a málo automatizovaný. Všetky fázy vývoja vrátane ladenia sú oddelené. Na vykonanie každého z nich sú potrebné špeciálne podmienky: písanie programového kódu sa vykonáva na plnohodnotnom počítačový systém, ladenie - na ladiacom systéme, testovanie - podľa okolností a pod. Samotný debugger v režime jadra je náročnejší na naučenie, a preto je menej užívateľsky prívetivý.
Vo všeobecnosti môžeme hovoriť o nedostatku nástrojov na ladenie jadra. Aj keď sú takéto nástroje k dispozícii, často nie je potrebné hovoriť o alternatívach. Napríklad ladiaci program Microsoft Windows má príliš vysoký vstupný prah. Mnoho programátorov hovorí o prvej negatívnej skúsenosti pri stretnutí s ním a väčšina jeho schopností zostáva nevyžiadaná.
Na základe štruktúry virtuálneho adresného priestoru, ak v aplikácii dôjde k chybe, v dôsledku ktorej aplikácia zapíše dáta do ľubovoľného pamäťového miesta, potom aplikácia poškodí iba svoju vlastnú pamäť a neovplyvní činnosť. iných aplikácií a operačného systému. Zatiaľ čo kód v režime jadra je schopný poškodiť dôležité dátové štruktúry operačného systému, čo nevyhnutne povedie k všeobecnému zlyhaniu. Neefektívne napísaný ovládač môže tiež spôsobiť vážnu degradáciu celého operačného systému.
- Moderné debuggery poskytujú nasledujúce základné funkcie:
- ladenie na úrovni zdrojového kódu;
- kontrola vykonávania;
- prezeranie a zmena pamäte;
- prezeranie a zmena obsahu registrov procesora;
- zobraziť zásobník hovorov.
Pre uľahčenie práce s rozobratým kódom, tzv. ladiace symboly. Počas spustenia linkera je možné okrem obrazu spustiteľného súboru vytvoriť aj dátový súbor, ktorý obsahuje informácie, ktoré nie sú potrebné pri spustení programu, ale sú mimoriadne užitočné pri jeho ladení: názvy funkcií, globálne premenné, popis štruktúr. Symboly ladenia sú dostupné pre všetky spustiteľné súbory operačného systému Windows.
Riadenie vykonávania sa týka schopnosti prerušiť a obnoviť vykonávanie programového kódu po dosiahnutí danej inštrukcie v programovom kóde. Ak sa programový kód vykoná v režime krok za krokom, prerušenie nastane pre každý symbol programovacieho jazyka alebo pri ukončení podprogramu. Pri bezplatnom spustení dôjde k prerušeniu vo vopred určených častiach kódu - miestach, kde sú nastavené zarážky.
Prerušenie kódu režimu jadra predstavuje nasledujúcu dilemu. Ladiaci program používa používateľské rozhranie na interakciu s programátorom. Tie. aspoň viditeľná časť debuggeru beží v užívateľskom režime a na jeho zostavenie prirodzene používa aplikačné programovacie rozhranie (Windows API), ktoré sa zasa spolieha na moduly režimu jadra. Pozastavenie kódu v režime jadra teda môže viesť k zablokovaniu: systém prestane reagovať na požiadavky používateľov.
Na prístup k pamäti jadra musia časti ladiaceho programu bežať aj v režime jadra. To vedie k vzniku dvoch problémov naraz, ktoré sú zjavným dôsledkom organizácie pamäte v chránenom režime procesora.
Prvý problém sa týka prekladu adries virtuálnej pamäte. Ovládače neustále interagujú s aplikáciami v používateľskom režime prostredníctvom prístupu k svojej pamäti. Operačný systém Windows prekladá virtuálne adresy na fyzické adresy podľa konceptu kontextu vlákna. Kontext toku je štruktúra, ktorá odráža stav toku a zahŕňa najmä súbor registrov a niektoré ďalšie informácie. Keď sa riadenie prenesie do iného vlákna, dôjde k prepnutiu kontextu, v ktorom sa uložia informácie o jednom vlákne a obnovia sa informácie o inom. Keď sa kontext vlákna prepne na vlákno iného procesu, prepne sa aj adresár stránok používaný na preklad virtuálnych adries na fyzické.
Zvláštnosťou je, že pri odosielaní systémových volaní operačný systém Windows neprepína kontext. To umožňuje kódu v režime jadra používať virtuálne adresy v používateľskom režime.
Iná je situácia pri odosielaní prerušení alebo pri vykonávaní systémových vlákien. Prerušenie môže nastať kedykoľvek, takže nemôžete predpovedať, ktorý kontext vlákna sa použije. Systémové vlákna nepatria do žiadneho procesu a nemôžu prekladať virtuálne adresy v užívateľskom režime. Z toho vyplýva, že v týchto situáciách nie je možný prístup do pamäte užívateľského režimu.
Druhým problémom je prístup k premiestniteľnej pamäti. Väčšina informácií v pamäti je premiestniteľná a kedykoľvek ju možno presunúť z fyzickej pamäte do HDD do súboru stránky. Ak pristúpite na stránku, ktorá sa nenachádza vo fyzickej pamäti, procesor normálne vygeneruje prerušenie Page Fault, o ktoré sa postará správca pamäte a v dôsledku toho bude stránka načítaná zo súboru stránky a načítaná do fyzickej pamäte.
Toto správanie je prerušené, ak je kód debuggeru nútený používať vysoké úrovne požiadaviek na prerušenie (IRQL). Ak sa IRQL zhoduje alebo prekračuje IRQL správcu pamäte, tento nebude môcť načítať chýbajúcu stránku, pretože operačný systém zablokuje prerušenie Page Fault. To spôsobí pád operačného systému.
Ladenie sa zvyčajne delí na interaktívne a núdzové. Pri interaktívnom lokálnom ladení ladiaci program beží na rovnakom systéme ako ladiaci objekt. Pri interaktívnom vzdialenom ladení beží ladiaci program a ladiaci objekt na rôznych systémoch. Pri ladení kódu jadra je potrebné systém monitorovať už od prvých fáz jeho zavádzania, keď sieť ešte nefunguje, preto sa na komunikáciu systémov používajú jednoduché sériové rozhrania ako COM, FireWire, USB. V poslednej dobe vďaka trendom vo vývoji virtualizácie softvéru na rôznych úrovniach abstrakcie virtuálne stroje stále viac lákajú. Hosťujúci OS funguje ako ladiaci OS, hosťovaný OS obsahuje používateľské rozhranie debuggera.
Núdzové ladenie teda nevyžaduje inštaláciu ladiaceho nástroja na testovacom stroji. Distribúcia operačného systému Windows obsahuje mechanizmy na implementáciu núdzového ladenia. Pred reštartom môže operačný systém uložiť informácie o svojom stave, ktoré môže vývojár analyzovať a zistiť príčinu. Tieto informácie uložené v súbore sa nazývajú výpis pamäte.
Základné nástroje na ladenie v režime jadra poskytuje výrobca operačného systému Windows ako súčasť bezplatného balíka Debugging Tools for Windows. Nástroje zahŕňajú grafické a konzolové debuggery WinDbg a KD (ďalej len Windows Debugger). Práca týchto debuggerov sa spolieha na mechanizmy poskytnuté vývojármi operačného systému a zabudované do jeho jadra.
Hlavným režimom programu Windows Debugger je režim tlmočníka príkazov. Vďaka modulárnej štruktúre spolu s dodanými vývojármi Príkazy systému Windows Debugger podporuje moduly tretích strán nazývané rozšírenia. V skutočnosti je väčšina vstavaných príkazov poskytovaná aj ako rozšírenia.
Windows Debugger je zameraný na vzdialené interaktívne a núdzové ladenie, pri použití sa odhalia všetky jeho schopnosti. Zároveň nie je podporované plnohodnotné lokálne interaktívne ladenie: debugger umožňuje len prezeranie niektorých štruktúr jadra.
Existuje zásuvný modul Windows Debugger s názvom LiveKD, ktorý vytvoril Mark Russinovich a ktorý v istom zmysle implementuje lokálne interaktívne ladenie. LiveKD vytvára výpis pamäte za behu pracovný systém a používa ho na ladenie.
Nástroje na ladenie pre Windows sa pravidelne aktualizujú, aby podporovali všetky moderné operačné systémy Windows.
Debugger jadra SoftICE od Compuware ako súčasť softvérového balíka DriverStudio je už tradične alternatívou k balíku Debugging Tools for Windows. Charakteristickou črtou SoftICE bola implementácia lokálneho interaktívneho ladenia na podporované hardvér... Debugger mal takmer úplnú kontrolu nad prevádzkou operačného systému.
K 3. aprílu 2006 bol predaj rodiny produktov DriverStudio prerušený z dôvodu „mnohých technických a obchodných problémov, ako aj všeobecných podmienok na trhu“. Najnovšia verzia Podporovaný operačný systém je Windows XP Service Pack 2. Balíky Service Pack zvyčajne nemenia rozhranie API operačného systému, ale čísla systémových hovorov a iné nezdokumentované informácie sa môžu zmeniť. Debugger SoftICE sa spoliehal na pevne zakódované adresy interných dátových štruktúr. V dôsledku toho bola kompatibilita s vydaním balíka Service Pack 3 narušená. Je zrejmé, že novšie verzie operačného systému Windows tiež nie sú podporované.
Syser Kernel Debugger bol vytvorený malou čínskou spoločnosťou Sysersoft ako náhrada za debugger SoftICE. Prvá finálna verzia bola vydaná v roku 2007. Rovnako ako SoftICE, aj Syser Kernel Debugger je schopný interaktívneho ladenia na spustenom systéme. Podporované sú iba 32-bitové vydania moderných verzií systému Windows.
V súčasnosti je Windows Debugger hlavným nástrojom medzi vývojármi modulov jadra. Používa ho aj tím jadra systému Windows.