isass.exe objekt nebyl nalezen

Podrobný start systému
Windows 2000/XP a řešení
možných chybových stavů
Semestrální projekt předmětu OS1
Vypracoval(a):
Obor:
Forma:
Ročník:
Datum:
E-mail:
Jana Molnárová
AI
Kombinovaná
1
10. 12. 2007
[email protected]
1.0 ÚVOD .................................................................................................................................3
2.0 PRE-BOOT SEKVENCE, START POČÍTAČE ...............................................................4
2.1. POST.............................................................................................................................5
3.0 BOOTOVACÍ SEKVENCE, START SYSTÉMU .............................................................8
3.1 Nástroj Recovery Console ..............................................................................................9
3.2 NTLDR .........................................................................................................................11
3.2.1. ARC cesty..............................................................................................................13
4.0 KERNEL LOAD (NATAŽENÍ JÁDRA SYSTÉMU)......................................................20
4.1. Smss .............................................................................................................................22
5.0 PŘIHLAŠOVACÍ SEKVENCE........................................................................................23
5.1 Winlogon.exe ...............................................................................................................23
5.2 Přihlašování uživatele z pohledu security...................................................................25
6.0 PROČ WINDOWS PADAJÍ A CO JE TO BSOD...........................................................27
6. 1 Analýza dump souborů ..............................................................................................29
7.0 ZÁVĚR ..............................................................................................................................34
8.0 PŘÍLOHY..........................................................................................................................35
Příloha 1 - Seznam všech souborů potřebných pro start systému....................................35
9.0 SEZNAM POUŽITÉ LITERATURY, ZDROJE A LINKY ..........................................37
9.1. Seznam použité literatury a zdroje ............................................................................37
9.2. Linky ........................................................................................................................... 37
Vysvětlivky

Tímto stylem je psán text popisující normální start systému (bootovací proces)

Tímto stylem je psán text, který reaguje na vzniklé problémy. Důvodem takového rozdělení
je přehlednost, text je opticky oddělený, ale zároveň neodtrhuje pozornost a neruší.
2
1.0 Úvod
Cílem této práce je porozumět celému pozadí procesu startu systému běžného
domácího/pracovního počítače s operačním systémem Windows 2000 nebo XP. Podle mého
názoru je to stále aktuální téma a není to tak jednoduchá věc, jak se na první pohled může
zdát. Navíc, pokud člověk tomuto procesu rozumí, má možnost hodně věcí ovlivnit - od času,
potřebného k nastartování systému, přes řešení vzniklých chyb až po šetření systémových
prostředků nebo optimalizaci programů a výkonu. Během své každodenní práce jsem
nasbírala velké množství pokladů k tomu, abych byla schopná takový proces pochopit, popsat
a rozvést a snad také přiblížit i ostatním čtenářům srozumitelnou a ucelenou formou.
3
2.0 Pre-boot sekvence, start počítače
Hned jak stiskneme tlačítko Power, provede zdroj energie autotest, ve kterém zkontroluje
zda jsou v pořádku všechna napětí a hodnoty. Pokud ano, vyšle procesoru signál „Power
Good“ a pokračuje v inicializaci. Pokud ne, počítač nenaběhne. S příchodem signálu „Power
Good“ se ukončí zasílání signálu RESET, a tím je dán pokyn procesoru, že může začít
zpracovávat první instrukce. Nejdříve začne zpracovávat kód ROM BIOSu, který je šestnáct
bajtů dlouhý a nachází se v nejvrchnější části paměti ROM na adrese FFFF:0000. Kód
bsahuje pouze Jump instrukci na aktuální adresu programu ROM BIOS.
Pokud odmítne počítač startovat už v téhle chvíli, často bývá příčinou zdroj a jeho
výměnou nebo pokud není poškozený, tak odpojením některých zařízení pro odlehčení, vše
spravíme. Z praxe také vím, že tenhle stav způsobuje zamáčklé či zapadlé tlačítko Reset.
Pre-boot sekvence pokračuje. ROM BIOSu nařídí základní test hardware pro ověření
základních funkcí. Chyby, které by se v tomto bodě bootovacího procesu vyskytly, by byly
oznámeny zvukovými signály, protože dosud není inicializovaný systém videovýstupu.
Bohužel, pro „pípání“ PC speakeru, neboli zvukové signály neexistuje žádný standard, ale
několik velkých firem jako Phoenix nebo American Megatrends uvádí seznam všech
možných stavů v manuálech k základním deskám nebo na svých webových stránkách. V praxi
to tedy znamená najít manuál, nebo otevřít bednu počítače (case), prohlédnout základní desku
a najít čip k BIOSu. V drtivé většině případů na něm bude samolepka a na ní nápis AMI nebo
Phoenix. Jako příklad dávám ukázku nejběžnějších zvukových kódů AMI BIOSu:
3 x krátký tón
5 x krátký tón
10 x krátký tón
1 dlouhý, 2 krátké
1 dlouhý, 3 krátké
1 dlouhý, 8 krátké
2 krátké
1 dlouhý
Chyba v prvních 64K paměti
Chyba procesoru
Chyba CMOS
Chyba video BIOS ROM nebo chybí grafická karta
Chybný součet paměti nad 64 KB
Chyba grafické karty, není nebo je poškozena
Selhání POSt testu
POST dokončil všechny testy
Tabulka 2.1.: Zvukové signály AMI BIOSu
Úplný seznam zvukových signálů AMI BIOSu, Phoenixu a dalších větších firem přikládám
jako linky na konci dokumentu ve zdrojích, protože jsou celkem rozsáhlé. Jen u firmy
Phoenix jsem napočítala celkem 166 možných stavů.
Někteří výrobci hotových počítačových sestav jako např. firma Dell už do svých nových
počítačů speaker vůbec nedávají. Zvukové signály byly nahrazeny blikáním malých LED
diodek, které jsou umístěné viditelně na přední straně krytu počítače. V manuálu pak najdeme
přehlednou tabulku s jejich vysvětlením.
4
Vyhledávač zařízení může vyžadovat zavedení vlastních ROM BIOS rutin přímo z
připojeného zařízení, takto zavádí své ovladače většina grafických karet. Startovací rutiny
BIOSu kontrolují paměťový prostor C000:0000 až C780:0000 video ROM a chyby v této
paměti jsou zobrazeny v podobě textové zprávy jako je např. tato: XXXX ROM Error (kde
XXXX označuje špatný adresový segment) ROM BIOS následně zjistí zda jde o teplý nebo
studený start. Pro toto zjištění se provedou rutiny BIOSu, které zjišťují hodnotu dvou bytů na
adrese 0000:0472. Pokud je tato hodnota jiná než 1234h, znamená to, že jde o studený start.
ROM BIOS provede úplný POST test. V opačném případě, když jde o teplý start je v POST
testech vypnut test paměti.
2.1. POST
POST je zkratka pro Power On Self Test a jedná se o malý diagnostický program, který
testuje všechen hardware zda je přítomný a připravený k práci. Pokud se nevyskytne žádná
chyba, která by byla zastavila testovací proces, většina tohoto testování je uživateli skryta a
probíhá velmi rychle. Vzniklé chyby oznamuje dvěma způsoby – již zmíněnými zvukovými
signály nebo pokud je inicializována grafická karta chybovými hlášeními. Výsledky těchto tří
testů jsou viditelné i uživateli:



Inicializace videokarty (a od tohoto okamžiku i zobrazování konfiguračních
informací nebo chybových hlášení, pokud je to potřeba)
Identifikace BIOSu, zobrazení verze, výrobce a data
Test všech paměťových čipů, přičemž se zobrazuje průběh načítání dostupné
instalované paměti
V tuto chvíli máme nahoře na obrazovce informace o výrobci naší základní desky, verzi
BIOSu, (ve většině případů) Energy Star logo a dole sériové číslo BIOSu.
Obrázek 2.1.: Start počítače, identifikace desky a BIOSu
5
Chyby, které se během POST testů vyskytnou mohou být klasifikovány jen do dvou stavů:
jako kritické nebo nepodstatné a do těch nepodstatných patří i informování uživatele o
průběhu inicializace. Kritické chyby ukončí bootovací proces a upozorní uživatele na vzniklý
stav zvukovými signály nebo chybovým hlášením. Nepodstatné chyby zobrazí chybové
hlášení, ale povolí systému pokračovat dál v bootovacím procesu. Pro představu přikládám
ukázku nejčastějších viditelných chybových hlášení Award BIOSu:
Informační, které nezastaví bootovací proces, ale informují uživatele:
HARD DISK initializing
MEMORY SIZE HAS CHANGED
SINCE LAST BOOT
Press ESC to skip memory test
Některé pevné disky potřebují více času pro inicializaci
Velikost RAM paměti počítače se změnila od posledního spuštění (zvětšila
nebo zmenšila)
Pokud chcete zastavit test paměti, stiskněte klávesu Escape
Pokud chcete přepnout obrazovku z klasické na zobrazení konfigurace
Press TAB to show POST screen
programu POST, stiskněte klávesu TAB (umožňují jen některé BIOSy)
Tabulka 2.2.: Informační hlášení, které běh systému nepřeruší
Obrázek 2.2.: Kritická chyba - ROM checksum error
Příklady kritických chyb, které vyžadují interakci s uživatelem, nebo úplně zastaví bootovací
proces:
CMOS battery failed
Keyboard error or no keyboard
present
Memory Test Fail
CMOS baterie už není funkční, prosím vyměňte ji
Chyba inicializace klávesnice. Buď chybí (není správně zapojená)
nepracuje správně nebo jsou permanentně stisklé některé klávesy.
POST test narazil na chybu během testování RAM paměti
Insert a system disk into drive A: and press Enter... Systém nenalezl
No boot device was found
MBR a nemůže pokračovat ve startu systému
Primary master hard disk fail
POST test narazil na chyby pevného disku během testů
SYSTEM HALTED. (CTRL-ALT-DEL) Bootovací proces musel být přerušen a počítač musí být restartován
TO REBOOT...
stiskem kláves CTRL + Alt + Delete.
Tabulka 2.3.: Kritické chyby, které zastaví bootovací proces
6
Pokud se počítač zastavil v této fázi bootování, bude nejlepší, když si opíšeme chybové
hlášení a výrobce BIOSu a pokusíme se najít vysvětlení na webových stránkách výrobce nebo
u odborníků. Některá dobře vybavená servisní centra mívají k dispozici zvláštní debugovací
POST rozšiřující kartu, která obsahuje seznam kódů všech nejpoužívanějších výrobců
základních desek a odhalit příčinu pro ně bývá otázkou několika minut, nicméně většina
těchto hlášek je intuitivní a uživatel zvládne nápravu sám.
Pokud se nevyskytla žádná chyba, pokračujeme v bootovacím procesu. BIOS vyhledá a
přečte konfigurační informace uložené v CMOS. CMOS je malá oblast paměti, která je
napájena z malé baterie umístěné na základní desce. Nejdůležitější informací v CMOS je pro
start systému proces pořadí zařízení, která budou zkoušena pro zavedení operačního systému
(disketa, CD/DVD nebo pevný disk). Na obrazovce v ten okamžik můžeme vidět tabulku
konfigurace počítače, ve které je například typ procesoru, disky a mechaniky, velikost
základní paměti nebo porty.
Obrázek 2.3.: Tabulka konfigurace
7
3.0 Bootovací sekvence, start systému
BIOS zjišťuje, zda úplně první sektor na zařízení, které bylo na prvním místě v pořadí
obsahuje Master Boot Record (MBR), nejčastěji je to pevný disk. Master Boot Record je
úplně první sektor na cylindru 0, hlavě 0, sektoru 1 a zabírá 512 bajtů. Pokud je tento sektor
nalezen, je narhán do paměti na adresu 0000:7C00 a konec MBR je otestován na přítomnost
hodnoty 55AA, která se nazývá End of Sector marker, tedy v překladu něco jako ukazatel
konce. Pokud tato hodnota chybí, BIOS tento stav vyhodnotí jako poškozený MBR nebo nový
pevný disk, který ještě nebyl formátován a vypíše na obrazovku příslušné chybové hlášení.
Když není MBR na prvním zařízení vůbec nalezen, opakuje BIOS celý postup hledání u
zařízení, které je nastaveno jako druhé, případně třetí v pořadí.
MBR je rozdělen na dvě části. Partition tabulku, která popisuje rozvržení pevného disku a
Partition loader, což je program potřebný pro pokračování v bootovacím procesu. Instalace
více operačních systémů na jednom počítači obyčejně zahrnuje i nahrazení originálního
loaderu bootovacím loaderem programu, který uživateli umožňuje vybrat konkrétní disk pro
další kroky procesu. Pokud je MBR zaveden do paměti předá se řízení inicializace Partition
loaderu, který zabírá většinu z jeho 512 bajtů. Partition loader zjistí v partition tabulce který
oddíl je označen jako aktivní a poté prohlédne první sektor této oblasti, zda obsahuje Boot
Record. Partition tabulka je 64 bajtů dlouhá datová struktura, která uchovává informace o
typu a lokaci jednotlivých oddílů na pevném disku. Každý zápis o oddílu je 16 bajtů dlouhý a
začíná na přesně daném místě, pokud tolik oddílů nemáme definováno, obsah daného zápisu
jsou samé nuly.
Boot Record je také 512 bajtů dlouhý a pokud ohlásí na konci opět hodnotu 55AA, MBR
ukončí řízení inicializace a předá ho Boot Recordu. Hlavní úkol Boot Recordu je vyhledat
soubory operačního systému. Pro DOS/Windows 95/98/ME je to IO.sys, pro systém Windows
NT/2000/XP je to NTLDR. Obsah Boot Recordu závisí na formátu souborového systému
pevného disku. Pokud je to FAT, Windows zapíší kód pro čtení FAT systému a Boot Record
obsahuje informace typu počet bajtů na sektor, počet sektorů na cluster apod. Pokud je to
NTFS, kód Boot Sectoru obsahuje přesně tolik kódu, aby dokázal číst strukturu disku a splnil
svůj úkol - nalézt NTLDR.
V případě chybného MBR, partition tabulky nebo kontrolní hodnoty se bootovací proces
přeruší s chybovou hláškou, která může vypadat například takto:
Obrázek 3.1.: Chybný MBR
8
NO ROM BASIC – SYSTÉM HALTED
nebo
No Boot Device Available (press F1 to retry boot)
nebo
No Boot Sector on Hard Disk
nebo
Missing Operating System
nebo
Invalid partition table
nebo
Error loading operating system
Všechna tato chybová hlášení znamenají to samé - bootovací proces nemůže dál
pokračovat, protože nenašel nic, čemu by předal řízení a co by nastartovalo (v tuto chvíli
zatím) jakýkoliv systém. Velké procento případů má na svědomí zapomenuté médium
(disketa, CD/DVD) v mechanice, které neobsahuje žádný systém a bootovací proces je
nastavený tak, aby prohledával disketovou mechaniku nebo CD/DVD mechaniku dříve než
pevný disk. Tady je řešení snadné, odstraňte médium, stiskněte klávesu enter a pokračujte
v bootovacím procesu.
Pokud to médiem není, může být na vině samotný pevný disk a je ho potřeba nahradit, nebo
je v pořádku, ale není na něm žádný operační systém, nebo tam systém měl být a teď je
poškozen. Pokud chceme nainstalovat nový operační systém, stačí vložit originální bootovací
CD s operačním systémem Windows 2000/XP a postupovat podle instrukcí na obrazovce,
nebo můžeme použít speciálně upravenou bootovací disketu v kombinaci s originálním
instalačním CD, pokud nám pouhé pozorování instalačního procesu nestačí a chceme některé
věci ovlivnit. Další možnosti jak nainstalovat nový systém jsou například instalace pomocí
sítě, bezodpovědní instalace nebo nahrání celé nové image disku pomocí programu nějaké
třetí strany, např. pomocí aplikace Norton Ghost. Předmětem této práce je však standardní
bootovací proces a náprava vzniklých chyb, takže se budeme zabývat poslední možností:
Operační systém měl být nalezen a je poškozený.
3.1 Nástroj Recovery Console
K opravě poškozeného systému Windows 2000/XP nám slouží nástroj Recovery Console.
Tento nástroj je v principu upravený příkazový řádek s omezenými funkcemi. Umožňuje
přístup ke svazkům se systémem souborů NTFS, FAT a FAT32, výpis služeb, nastartovat
nebo zastavit službu pro další spuštění systému, přistupovat do rootu disku, do systémového
rootu a do složky /cmdcons a dokáže opravit boot sektor nebo masterboot record. Jak spustit
nástroj Recovery Console?
Předpokládejme, že máte v BIOSu povolené bootování z CD. Vložte originální bootovací
CD systému Windows 2000 nebo XP a na úvodní obrazovce stiskněte klávesu F10, nebo pro
možnosti opravy systému stiskněte klávesu R, a poté klávesu K. Spustíte tak Konzolu pro
zotavení.. Zvolte číslo instalace systému Windows, kterou chcete opravit, a poté zadejte heslo
administrátora. (Pokud nebylo heslo administrátora zadáno, stiskněte pouze klávesu enter)
9
Malé upozornění: Pokud zadáte heslo třikrát špatně, nástroj Recovery Console se ukončí a
restartuje počítač.
Obrázek 3.2.: Nástroj Recovery Console
Pro obnovu MBR/Boot sektoru zadejte příkaz fixmbr a fixboot. Pro ukončení nástroje a
restartování počítače zadejte příkaz exit. Úplný seznam příkazů nástroje Recovery Console
přikládám na konci dokumentu v sekci zdroje jako link.
Nástroj Recovery Console jde přidat do úvodní spouštěcí nabídky systému zadáním
příkazu Winnt32.exe s parametrem /cmdcons, bohužel ne chvíli, kdy je systém poškozen, ale
předvídavě předem. Existuje i možnost, že nám nástroj Recovery Console nepomůže, sám se
ukončí a počítač musí být přeinstalován. To se stane ve chvíli, kdy schází nebo je poškozená
databáze účtů SAM a není možné ověřit účet administrátora, který se pokouší o přihlášení.
Další možnosti jak opravit poškozený systém jsou nahrání celé nové image disku, pokud je
k dispozici nebo použití bootovacího Windows live CD. Live CD je operační systém uložený
na bootovatelném CD, který může být rovnou spuštěn bez nutnosti instalace na pevný disk
nebo zdlouhavé konfigurace. Obrovskou výhodou je, že se počítač znovu vrátí ke svému
původnímu systému hned jak je Live CD vyjmuto a počítač restartován. To je možné díky
tomu, že data nejsou ukládána na pevný disk, ale do dočasné paměti, jako je RAM. První Live
CD se objevilo zhruba před třemi lety s linuxovými distribucemi a dnes už tak můžeme
přizpůsobit i systém Windows XP, který díky tzv. Preinstalled Environment (PE) může běžet
přímo z CD/DVD, podobně jako jiné linuxové distribuce (například Knopixx). CD kromě
samotného systému obsahuje nejrůznější utility třetích stran, které pomáhají uživatelům
s řešením nejrůznějších problémů, podporu sítí (včetně klienta pro Netware a VNC) nebo
různé monitorovací nástroje a velkou výhodou je bezproblémová podpora diskových oddílů
s NTFS. Ne všechny linux Live CD si s NTFS poradí. Live CD si můžeme sestavit sami,
pokud vlastníme originální Windows 2000/XP CD a je možné jej celkem pohodlně měnit
nebo rozšiřovat pomocí utilit na stránkách internetu o další nástroje nebo ovladače. Více
informací o live CD najdete na konci dokumentu ve zdrojích mezi linky.
10
3.2 NTLDR
Pokračujeme v bootovacím procesu, který teď bude řídit NTLDR, protože jsme zvolili
systém Windows 2000 nebo XP. Jde o skrytý systémový soubor, který se nachází v
kořenovém adresáři systémového oddílu a je proveden ve čtyřech fázích:




Fáze inicializace
Výběr operačního systému
Detekce hardware
Výběr hardwarové konfigurace
NTLDR ve fázi inicializace nejdříve startuje mini FAT a NTFS ovladače, které obsahuje
přímo ve svém kódu. Kód Boot sektoru používaný doteď si nedokáže poradit ani s podadresáři a
a prohledává pouze root disku. Pokud používáme SCSI disky, kód NTLDR si s jejich čtením
sám poradit neumí a inicializuje soubor Ntbootdd.sys. Dále zapíná stránkování a přepíná
procesor z reálného do protected módu. V reálném režimu nedochází k žádnému překladu
paměťových adres z virtuálních na fyzické s to znamená, že je přístupný pouze první megabajt
fyzické paměti počítače. V protected módu a se zaplým stránkováním zpřístupňuje 32bitové
adresování paměti a to znamená, že od této chvíle dokáže pracovat až se 4 GB fyzické paměti.
Celý proces inicializace systému se zastaví, pokud kód boot sektoru nedokáže NTLDR
v rootu disku najít a vypíše toto chybové hlášení:
Obrázek 3.3.: Chybějící NTLDR
Naším řešením je opět nástroj Recovery Console. V příkazovém řádku konzoly napište
příkaz map a potvrďte klávesou enter. Pak následují příkazy:
copy D:\i386\ntldr c:\ (enter)
copy D:\i386\ntdetect.com c:\ (enter)
Všechny důležité soubory jsou zkopírovány, restartuje počítač. V případě, že by vám tento
postup nepomohl, můžete zkusit místo kopírování souborů zadat v příkazovém řádku příkazy
- fixmbr a poté fixboot nebo opět Windows live CD a přehrání souborů ze zálohy.
11
NTLDR pokračuje v inicializaci a vyhledává soubory, které pro bezproblémový chod
počítače existovat nemusí, ale pokud existují, tak ovlivňují start systému. Seznam souborů,
potřebných pro start přikládám na konci dokumentu jako přílohu číslo 1.
Pokud v této fázi nalézá „aktivní“ soubor Hiberfil.sys, předá se startovací proces kódu
jádra, který se stará o hibernaci a postupně se obnoví systém do stavu před hibernací. Aktivní
znamená, že jeho čas vytvoření se shoduje s časem posledního vypnutí systému. Soubor
Hiberfil.sys mimo jiné obsahuje „full memory image“, tedy uloženou celou paměť ve chvíli
hybernace a ARC cestu k boot partition, která byla použita pro start systému před hybernací.
Pokud soubor Hiberfil.sys nalezen není, NTLDR pokračuje dál v inicializaci systému.
Další soubor, který NTLDR hledá je boot.ini a tím se také dostáváme k fázi číslo 2, výběru
operačního systému. Pokud je boot.ini v kořenovém adresáři nalezen načte jeho obsah do
paměti a když obsahuje záznamy o více než jednom operačním systému, zastaví se na tomto
bodě a vyčká se na uživatelův výběr. Jestliže soubor boot.ini v kořenovém adresáři není,
pokračuje v bootovací sekvenci nahráním systému z prvního oddílu prvního disku, kterým je
běžně C:\.
Obrázek 3.4.: Výběr operačního systému
Boot.ini je systémový, skrytý a pouze pro čtení (read only a hidden), ale můžeme do něj
zasahovat, když tyto atributy dočasně zrušíme. Standartně se nachází v rootu disku a může
vypadat např. takto:
[boot loader]
timeout=20
default=multi(0)disk(0)rdisk(0)partition(4)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(4)\WINNT="Microsoft Windows 2000 Server" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Professional"
/fastdetect
12
multi(0)disk(0)rdisk(0)partition(1)\NTWORK="Windows NT Workstation, verze 4.00"
multi(0)disk(0)rdisk(0)partition(1)\NTWORK="Windows NT Workstation, verze 4.00 [VGA]"
/basevideo /sos
C:\="Microsoft Windows"
Seznam přepínačů souboru Boot.ini přikládám na konci dokumentu v sekci linky. Pokud
uživatel nevybere žádnou položku ze spouštěcí nabídky v určitém čase, zadaném v souboru
Boot.ini jako položka timeout, Ntldr zvolí výchozí možnost, kterou je reprezentuje položka
„default=“. Pokud čeká počítač příliš dlouho než sám vybere operační systém, stačí upravit
soubor Boot.ini v některém vašem oblíbeném textovém editoru nebo pomocí grafických
nástrojů ve Windows jako Msconfig, Startup and recovery nebo Bootcfg.exe, který se však
poprvé objevil až ve Windows XP. Položka, která je zodpovědná za čas poskytnutý k výběru
systému se jmenuje „timeout“ a patří do sekce [boot loader]. Všechny volby obsažené v
Boot.ini se ukládají do hodnoty registru HKLM\System\CurrentControlSet\Control\
SystemStartOptions.
3.2.1. ARC cesty
Pro výběr více systémů slouží ARC (Advanced Rics Computing) cesty jako např. tato:
multi(0)disk(0)rdisk(0)partition(1). Jak to funguje?
multi or scsi(x)disk(z)rdisk(a)partition(b)\%SystemRoot%
Pořadové číslo řadiče IDE nebo SCSI adaptéru s BIOS. (Vždy 0)
Pořadové číslo pro kartu SCSI bez BIOSu
Pouze pro SCSI - disk ID. Při použití multi je toto nastavení vždy 0.
Číslo disku na řadičích IDE (EIDE), 0 první, 1 druhý... SCSI je vždy 0
Číslo oddílu 1,2,3,4... (primární oddíly jsou vždy před rozšířenými oddíly
a logickými disky)
\%SystemRoot% Adresář s Windows. Nejčastější a výchozí nastavení je winnt
multi(x)
scsi(x)
disk(z)
rdisk(a)
partition(b)
Tabulka 3.2.1.: Složení ARC cest
Obrázek 3.5.: Rozdělení disků
13
C:\ = multi(0)disk(0)rdisk(0)partition(1)
D:\ = multi(0)disk(0)rdisk(0)partition(2)
E:\ = multi(0)disk(0)rdisk(1)partition(3)
F:\ = multi(0)disk(0)rdisk(1)partition(1)
G:\ = multi(0)disk(0)rdisk(1)partition(4)
H:\ = multi(0)disk(0)rdisk(1)partition(2)
I v téhle fázi inicializace se může stát, že se proces přeruší. Pokud soubor Boot.ini
neexistuje a NTLDR nedokáže najít ani %systeomroot%, nebo přidáte/odeberete některou
z partiton tabulek a zapomenete aktualizovat soubor boot.ini, objeví se toto chybové hlášení:
Obrázek 3.6.: Poškozený soubor Boot.ini
Nebo hlášení: Windows could not start because the following file is missing or corrupt:
\winnt root\ system32\ntoskrnl.exe. Řešením je dohrání/update souboru boot.ini
Pokud máte originální bootovací CD, existuje ještě jeden způsob opravy. Vložte CD do
mechaniky a restartujte počítač a v nabídce opět zvolte R pro nástroj Recovery Console.
Zvolte systém, zadejte administrátorské heslo a počkejte až se objeví příkazový řádek. V něm
pak napiště příkaz bootcfg /rebuild a sledujte instrukce na obrazovce. Příkazem exit ukončíte
nástroj Recovery Console a počítač se restartuje.
Obrázek 3.7.: Příkaz bootcfg /rebuild
14
Pokračujeme v bootovací sekvenci, kterou stále řídí NTLDR. V případě, že Boot.ini
obsahuje nabídku několika různých systémů a vybereme DOS, Windows 95 nebo 98, NTLDR
vyhledá a nahraje soubor Bootsect.dos, který hledá standartně v rootu systémového disku.
Bootsect.dos pak inicializuje soubory IO.sys, MSDOS.sys a command.com. Tyto systémy
však nejsou předmětem mé práce, takže opouštíme tuto cestu a předpokládejme, že
zaváděným systémem je Windows 2000 nebo XP. Pro ně inicializuje NTLDR soubor
Ntdetect.com a dostáváme se k posledním dvěma fázím NTLDR, detekci hareware a výběru
hardwarového profilu.
Soubor Ntdetect.com provede detekci hardware, vytvoří seznam aktuálně nainstalovaných
hardwarových komponent a vrací jej pro pozdější zahrnutí do registrů pod klíčem
HKEY_LOCAL_MACHINE\HARDWARE. Ntdetect.dom se dotazuje (BIOSu) na informace
typu:

Datum a čas, uložený ve CMOS

Druhy sběrnic (ISA, PCI, EISA apod.) a porty

Počet, velikost a typ pevných disků, existence disketové mechaniky

Druh a počet vstupních zařízení (myš, klávesnice)

Druh a parametry grafické karty
Získané informace jsou předané NTLDR a následně uložené v registrech, v klíči
HKEY_LOCAL_MACHINE\HARDWARE\ DESCRIPTION, později po startu k použití.
Pro systém Windows 2000 je v tuto chvíli vidět černá obrazovka a v její spodní části narůstá
postupně bílý pruh (starting Windows progress bar). U Windows XP už můžeme v tu samou
chvíli vidět grafické prostředí a barevné logo.
Obrázek 3.8.: Startující Windows XP
15
Obrázek 3.9.: Windows 2000 progress bar
Každý kousek Windows 2000 progress baru navíc znamená jeden celý úspěšně nahraný
ovladač a standartně jich je něco kolem 80ti. (počet dílků nesouhlasí, na každý ovladač
připadá 1.25% dílku). Pozor, ovladače jsou zatím jen nahrávány do RAM paměti, ale nejsou
inicializovány. Pokud je zapnut přepínač Boot.ini /SOS, který způsobí vypsání názvů souborů
místo grafické podoby bootu, ukazuje jen seznam nahrávaných ovladačů. Pokud se tento
seznam na některém z nich zastaví, neznamená to, že je to ten, který způsobuje potíže.
Pod progress barem je zpráva „For troubleshooting and advanced startup options for
Windows2000, press F8“ (Pro řešení potíží nebo upřesnění možností spuštění – stiskněte
klávesu F8). Stiskne-li uživatel klávesu F8, nabídne mu systém rozšířenou nabídku spuštění
Obrázek 3.10.: Startovací nabídka systému Windows 2000 v případě potíží
16

Stav nouze - Spustí systém jen s těmi nejzákladnějšími soubory a drivery, nenahraje
podporu sítě. Co se spustí je v klíči HKLM\System\CurrentControlSet\Control\Safeboot\
minimal. Ve stavu nouze můžeme využívat veškerá zařízení jen se základním nastavením
(například grafickou kartu), ale i to stačí ke kontrole logů, protokolů, ke spuštění
diagnostických programů nebo odstranění špatných driverů. Pokud nám nenabíhá systém ani
ve stavu nouze, pak nám zbývá už jen Recovery Console a příkaz disable, protože driver,
který pád systému způsobuje je zřejmě používán i pro režim nouze (opět například grafická
karta)

Stav nouze s prací v síti - Spustí systém jen s těmi nejzákladnějšími soubory a drivery, ale i
s podporou práce v síti. Co se spustí je v klíči HKLM\System\CurrentControlSet\Control\
Safeboot\ network

Stav nouze s příkazovým řádkem - Spustí systém jen s těmi nejzákladnějšími soubory a
drivery, nenahraje podporu sítě. Po dokončení spustí příkazový řádek (režim MS-DOS).

Při zavádění povolit protokolování - Tato možnost vytvoří zaváděcí protokol o procesu
startu systému, který uloží do souboru ntbtlog.txt (pro systém Windows 2000 i XP) v rootu
systému.
Příklad souboru logu:
Microsoft (R) Windows 2000 (R) Version 5.0 (Build 2195)
2 11 2000 10:53:27.500
Loaded driver \WINNT\System32\ntoskrnl.exe
Loaded driver \WINNT\System32\hal.dll
Loaded driver \WINNT\System32\BOOTVID.DLL
Loaded driver ACPI.sys
Loaded driver \WINNT\System32\DRIVERS\WMILIB.SYS
Loaded driver pci.sys
Loaded driver isapnp.sys
Loaded driver compbatt.sys
Loaded driver \WINNT\System32\DRIVERS\BATTC.SYS
Loaded driver intelide.sys
Loaded driver \WINNT\System32\DRIVERS\PCIIDEX.SYS
Loaded driver pcmcia.sys
Loaded driver ftdisk.sys
Loaded driver Diskperf.sys
Loaded driver dmload.sys
Loaded driver dmio.sys
Did not load driver Media Control Devices
Did not load driver Communications Port
Did not load driver Audio Codecs
Každý řádek, který začíná slovy Did not load driver... by nám měl napovědět kde je
chyba. Pro analýzu těchto souborů existuje jen jeden nástroj jménem Bootlog Analyser, ale
jeho nevýhdou je, že nelze sehnat samostatně a zdarma. (Je součástí balíku produktů jménem
RegRun)
17

VGA režim - Tato volba spustí systém s použitím základního VGA ovladače grafiky. Tato
možnost spustí systém Windows v režimu 640 x 480 s aktuálním grafickým ovladačem (ne s
ovladačem Vga.sys). Tento režim je užitečný, pokud bylo zobrazení nastaveno tak, že je
daný monitor nezvládne.

Poslední známá dobrá konfigurace - Po každé úspěšně ukončené bootovací sekvenci, která
končí přihlášením uživatele si systém automaticky vytvoří kopii seznamu aktuální
kombinace ovladačů a systémových nastavení (HKLM\System\Control00n, kde 00n je
následující volné číslo) a uloží je jako poslední známou dobrou konfiguraci a předchozí
smaže. Tato uložená data mohou být použita příště, pokud přidání nového zařízení povede k
chybnému startu systému. Volba last known good configuration neřeší problémy vzniklé po
přihlášení, SAM databázi ani problémy se software.

Režim obnovení adresářových služeb - Tato možnost obnoví službu Active Directory na
serveru - řadiči domény. Volba je dostupná pouze na řadiči domény.

Režim ladění - Při této volbě budou během spouštění systému zasílány informace sériovým
kabelem jinému PC, na kterém běží nastavený ladící program, například Windbg.
Předpokládejme, že běh systému upravovat nechceme a klávesu F8 nepoužijeme. Proces
inicializace systému stále řídí NTLDR a na řadě je jeho poslední fáze – výběr hardwarové
konfigurace počítače. Pokud je v systému definováno více hardwarových profilů, zobrazí
menu s nabídkou a čeká se na uživatelův výběr. Pokud používáme pouze jeden hardwarový
profil, NTLDR tento krok přeskočí a menu nezobrazí.
Jeden z posledních úkolů, které NTLDR provede než odevzdá řízení startu počítače je
nalézt soubory Ntoskrnl.exe a Hal.dll a nahrát je do paměti. Ntoskrnl.exe je mini-jádro
systému a po jeho úspěšném nahrání mu NTLDR předá řízení a soubor Hal.dll (Hardware
Abstraction Layer) bude oddělovat toto mini-jádro systému od hardware.
Tady se můžeme setkat s dalším přerušením bootovacího procesu nebo v extrému s BSOD,
(více o BSOD v kapitole 6) a restartem počítače. Pokud dojde k poškození systémových
souborů Ntoskrnl.exe nebo Hal.dll nebo některý ze souborů úplně chybí, objeví se toto
chybové hlášení:
Obrázek 3.11.: System hive corruption
18
Obrázek 3.12.: Poškozené systemové soubory nebo chybějící HAL.DLL
Řešením je opět Recovery Console a použití příkazů pro kontrolu nebo přehrání
systémových souborů.
Pokud se nás žádná z výše uvedených chyb netýká, NTLDR pokračuje. Jak jsou postupně
nahrávány ovladače zařízení do paměti, třídí je do skupin a zapisuje o nich informace do klíče
registru HKLM\SYSTEM\CurentControlSetO\Services. Ovladače mají své přesně dané
pořadí startu, a to je zapsané v klíči HKLM\SYSTEM\CurentControlSetO\Control\Service
GroupOrder. Ty, které mají nastavenu startovací hodnotu Service_Boot_Start 0 (0x0) budou
zavedeny jako první. Zapsáním informací o ovladačích práce NTLDR končí, předává řízení
načtenému souboru Ntoskrnl.exe a opouští inicializaci systému.
Hodnoty v klíči HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
0x0 = Boot
0x1 = System
0x2 = Auto
0x3 = Manual
0x4 = Disabled
Ovladače jsou nahrány do paměti pomocí NTLDRL, inicializovány
pomocí Ntoskrnl během inicializace jádra systému
Ovladače jsou nahrány a inicilaizovány pomocí Ntoskrnl během
inicializace jádra
Nahrány a startovány automaticky po startu systému
Ovladač je inicializován manuálně nebo pomocí jiného procesu
Ovladač nebude inicializován
Tabulka 2.4.: Pořadí ovladačů při startu systému
19
4.0 Kernel load (natažení jádra systému)
Bootovací proces je přednán souboru Ntoskrnl.exe. Ntoskrnl.exe je považován za minijádro systému a spolu se souborem Hall.dll v této fázi startu počítače inicializují výkonné
subsystémy a ovladače zařízení, připravují systém na start nativních aplikací a spouští
smss.exe, který je zodpovědný za za vytvoření viditelného uživatelského prostředí.
Ntoskrnl je vykonáván ve dvou fázích - fáze 0 a 1 a jeho nejdůležitějším úkolem je zavolat
hned na začátku fáze 0 funkci KiSystemStartup, která volá HalInitializeProcessor a
KiInitializeKernel. Během fáze 0 jsou zakázána přerušení a smyslem této fáze je pouze
vybudovat prostředí pro volání služeb ve fázi 1. Jsou inicializovány tyto subsystémy,
označovány jako Executive:







Object Manager (vytváří, řídí a maže objekty, které představují zdroje systému, např
procesy nebo vlákna)
Microkernel (v tuto chvíli Ntosrknl.exe a Hal.dll, některé ovladače)
Security Reference Monitor (stará se o bezpečnostní politiku lokálního počítače)
Memory manager (řídí virtuální paměť, kontroluje stránkování a umožňuje práci s
reálnou pamětí)
Cache Controller (řídí operace s načítáním a předáváním bloků souborů v cache)
I/O Manager (řídí vstup a poskytuje výstup pro různá zařízení)
Process Manager (vytváří, ukončuje a pozastavuje procesy a vlákna programů)
Ve fázi 1 je zavolán soubor Hall.dll a jeho funkce HalInitSystem, která přebere řízení
přerušení a oddělí jádro systému (nyní Ntoskrnl) od hardware. Zinicializuje se ovladač
grafické karty Bootvid.dll, díky kterému se na obrazovce systému Windows 2000 objeví
přibývající Starting Windows progress bar, tentokrát na bílém pozadí s logem. Windows XP
mají tuto fázi inicializace také, ale místo bílé obrazovky vidíme opět již známou černou
s logem, jako předtím vykreslil NTLDR.
Obrázek 4.1.: Grafický Windows progress bar
20
Ani v tomto případě progres bar nepřibývá náhodně, ale o přesně daný počet procent za
každý dokončený úkol:

Prvních 5% progress baru se objeví po inicializaci správce napájení, inicializaci
systémového času a inicializaci zbylých procesorů, pokud v počítači nějaké jsou.

Na 10% přeskočí ve chvíli, kdy jádro inicializuje datové struktury plánovače a tabulku
odesílání systémových služeb, správce objektů vytvoří kořenový adresář objektů (object
manageru) „\“, adresář „\ObjectTypes“ a adresář mapování názvů zařízení DOSu. „\??“
pro Windows 2000 a “\Global??“ pro Windows XP. Monitor bezpečnostních referencí
vytvoří adresář \Security a zapne auditování.

Je zavedena podpora jazyků (soubor Internat.exe), načte se soubor Ntdll.dll, správce
cache inicializuje svá pracovní vlákna a do object manageru jsou nataženy klíče registrů
pro pozdější použití. S inicializací Plug & Play poskočí progress bar o dalších 10%.

Inicializace subsystému pro lokální volání procedur a inicializace protokolovacího
souboru bootlog.txt, (pokud byl systém spuštěn s protokolováním, parametrem /bootlog)
posune progress bar o dalších 5%. Celkem jsme na 25%.

Nejvíce práce odvede a nejvíce procent na progress baru přibyde díky inicializaci I/O
manažera. (Manažer vstupů a výstupů). Každý zavedený ovladač, který měl být
inicializován při startu systému posune bar o 2% a standartně je jich 25. Windows
progress bar tedy poskočí až na 75%. Je inicializováno WMI (Windows management
instrumentation) a nakonec se v oboru názvů správce objektů vytvoří názvy zařízení
systému MS-DOS jako symbolické názvy.

Spouští-li se počítač v bezpečném režimu, zaznamená se tato informace do registru a
aktivuje se stránkování kódu v režimu jádra (v Ntoskrnl a ovladačích). Progress bar se
posouvá na 80%.

Správce napájení inicializuje struktury napájení a to posune progress bar o dalších 5%.

Je vytvořeno vlákno příkazového serveru komunikující s LSASS (subsystém pro lokální
ověřování zabezpečení) a progress bar je na 90%.

Posledním krokem, který posune progress bar na 100% je zavolání smss.
21
4.1. Smss
SMSS (Session Manager), je zodpovědný za vytvoření viditelného uživatelského prostředí.
Spouští grafický subsystém (Win32k.sys), Csrss.exe a přihlašovací proces (Winlogon). Běží v
uživatelském módu, ale na rozdíl od jiných aplikací v tomto módu je nedílnou součástí
operačního systému a to znamená, že je nativní a využívá jen výkonné vnitřní funkce. Vlákno
smss vykonává mnoho dalších věcí:

Jsou startovány programy uvedené v HKLM\System\CurrentControlSet\Control\Session
Manager\BootExecute, což je například checkdisk nebo se mohou dokončovat instalace,
které nemohly být dokončené bez restartu systému (potřebují přepsat část systému, která
byla používána nebo přesunout některé důležité sustémy)

Jsou-li nainstalovány terminálové služby, vytvoří se podaresář \Sessions. Jsou otevřeny
známé .dll knihovny a vytvoří se objekt \Knowndlls

Vytvoří se dodatečné stránkovací soubory. Konfigurace je uložena pod klíčem HKLM\
System\CurrentControlSet\Control\SessionManager\MemoryManagement\PagingFiles.

Inicializuje se registr, HKLM\SAM, HKLM\SECURITY, HKLM\SOFTWARE. I když
jsou soubory na disku uvedeny v klíči HKLM\SYSTEM\CurrentControlSet\Control\
hivelist, správce konfigurace je vytvořen tak, aby je hledal ve \windows\System32\Config

Vytvoří se systémové proměnné a jsou definovány v klíči HKLM\SYSTEM\
CurrentControlSet\SessionManager\Enviroment.

Je zaveden Win32k.sys, který pracuje v režimu jádra. Inicializační kód ve Win32k.sys se
používá k přepnutí obrazovky z režimu VGA na rozlišení definované výchozím profilem.

Spuuští se Csrss.exe. Csrss je client/server run-time subsystem a zodpovídá za okna
konzolí, vytváření a odstraňování podprocesů a některé části 16bitového virtuálního
prostředí systému MS-DOS.

Je volán Winlogon a spouští se přihlašovací proces
Bootovací proces se považuje za téměř za dokončený. Uživateli je zobrazeno dialogové
okno Preparing network connections přesně ve chvíli, kdy subsystém služeb skončil s
inicializací síťových služeb.
´
Obrázek 4.2.: Připraveno k přihlášení
22
5.0 Přihlašovací sekvence
5.1 Winlogon.exe
Dostáváme se k poslední části startu systému, a to k přihlášení uživatele. Přihlášení nám
zprostředkuje soubor Winlogon.exe, který je nahrán kernelem jako služba. Spouští Lsass a
services.exe. Proces Winlogon koordinuje přihlášení, během přihlašování spouští uživatelův
první proces, obsluhuje odhlášení a řídí různé další operace týkající se zabezpečení, včetně
zadávání hesel během přihlášení, změny hesel a uzamykání či odemykání pracovní stanice.
Proces Winlogon musí zajistit, že operace související s bezpečností nejsou viditelné pro žádný
jiný aktivní proces a je to jediný proces, který zachycuje požadavek přihlášení přicházející
z klávesnice.
Proces Winlogon spoléhá při získávání jména a hesla uživatelského účtu na grafickou
identifikační a autentizační knihovnu nazývanou GINA (Graphical Identification and
Authentication). Standardní knihovnou GINA je Msgina (\Windows\System32\Msgina.dll).
Msgina je zodpovědná za standardní přihlašovací dialogové okno Windows. Tím, že
Windows dovolují nahradit standardní GINA knihovnu jinými, (v klíči HKLM\Software\
Microsoft\Windows\CurrentVerison\WinLogon\GinaDLL) umožňují systému používat
rozdílné mechanismy pro identifikaci uživatelů. Výrobci software mohou dodat vlastní GINA
knihovnu, která například používá pro identifikování uživatelů zařízení na rozpoznávání
otisků prstů a jejich hesla získává ze zašifrované databáze.
Obrázek 5.1.: Zadávání uživatelského jména a hesla pro systém XP
23
Obrázek 5.2.: Zadávání uživatelského jména a hesla pro systém 2000
Uživatel je vyzván ke stisku kombinace kláves ctrl + alt + delete a po získání uživatelského
jména a hesla volá Winlogon proces Lsass, aby ověřil uživatelův pokus o přihlášení. Pokud je
uživatel autentizován, aktivuje přihlašovací proces jeho jménem nadstavbu prostředí. Kromě
podpory alternativních knihoven GINA může proces Winlogon zavádět i přídavné knihovny
síťových poskytovatelů, kteří vyžadují sekundární autentizaci. Tato schopnost dovoluje získat
identifikační a autentizační informace pro více síťových poskytovatelů najednou během
normálního přihlášení: Uživatel přihlašující se do systému Windows může být současně
autentizován i na unixovém serveru aniž by musel podstoupit další ověřování. Pokud není
logovací proces přerušen změnou hesla nebo zadáváním nového, inicializace pokračuje.
Předtím než je aktivní jakákoliv uživatelská aplikace, provádí proces Winlogon následující
akce:

Vytváří a otevírá objekt window station (objekt \Windows\WindowStations\WinSta0
ve jmenném prostoru správce objektů), který reprezentuje klávesnici, myš a monitor.
Proces Winlogon vytváří pro stanici jedinečnou bezpečnostní identifikaci, která
zajišťuje, že žádný jiný proces nemůže přistupovat k pracovní stanici bez výslovného
souhlasu procesu Winlogon.

Vytváří a otevírá dvě pracovní plochy: aplikační pracovní plochu (\Windows\
WinSta0\Default, známou jako pracovní plocha) a pracovní plochu procesu Winlogon
(\Windows\WinSta0\Winlogon, známou jako zabezpečená pracovní plocha).
Bezpečnost pracovní plochy Winlogon je zajištěna tím, že k ní může přistupovat
pouze proces Winlogon. Na ostatní pracovní plochy přistupují proces Winlogon i
uživatelé. Toto uspořádání znamená, že v okamžiku, kdy je aktivní zabezpečená
pracovní plocha, nemá žádný jiný proces přístup k jakémukoliv kódu nebo datům
z pracovní plochy. Windows používají tuto vlastnost k zabezpečení operací s hesly a
k uzamknutí či odemknutí pracovní plochy. Dříve než se kdokoli může přihlásit do
počítače, je viditelnou pracovní plochou plocha procesu Winlogon. Po přihlášení
uživatele znamená jakékoliv stisknutí kláves Ctrl + Alt + Delete přepnutí z výchozí
pracovní plochy zpět na plochu Winlogon a to také vysvětluje, proč všechna okna
Vaší pracovní plochy po stisknutí kombinace Ctrl + Alt + Delete zmizí a vrátí se až
poté, co opustíte dialogové okno opustíte. Sekvence Ctrl + Alt + Delete vždy předloží
24
bezpečnou pracovní plochu řízenou procesem Winlogon. Tento mechanismus zabrání
například programům typu trojský kůň v získání kontroly nad pracovní plochou
v okamžiku stisknutí Ctrl + Alt + Delete.

Sestavení spojení LPC s portem LsaAuthenticationPort procesu Lsass. Toto spojení
se použije k výměně informací během přihlášení, odhlášení a operací s heslem.
Jakmile se pracovní plocha procesu Winlogon během inicializace vytvoří, stává se z ní
aktivní pracovní plocha. Když je zabezpečení plocha Winlogon aktivní, je vždy uzamknuta.
Proces Winlogon plochu odemkne jen při přepnutí na pracovní plochu aplikace nebo na
plochu spořiče obrazovky. Samozřejmě, pracovní plochu dokáže zamknout nebo odemknout
jen proces Winlogon.
5.2 Přihlašování uživatele z pohledu security
Přihlašování začíná v okamžiku, kdy uživatel stiskne sekvenci Crl + Alt + Delete. Po jejím
stisknutí zavolá proces Winlogon knihovnu GINA, aby získala z přihlašovacího dialogu
jméno a heslo uživatele. Proces Winlogon vytvoří pro uživatele jedinečný místní přihlašovací
identifikátor SID, který přiřadí této instanci pracovní plochy (klávesnici, obrazovce a myši).
V případě, že je uživatel úspěšně přihlášen, dostane se identifikátor SID do tokenu
přihlašovacího procesu a to je krok, který chrání přístup k pracovní ploše. Další přihlášení pod
stejným účtem, ale na jiném počítači nebude moci zapisovat do pracovní plochy prvního
počítače z toho důvodu, že druhé přihlášení bude mít jiný token pracovní plochy než ten z
prvního přihlášení.
Z pohledu security jsou pro nás v tuto chvíli zajímavé především autentizační balíčky, které
musí Winlogon získat od procesu jménem Lsass. Seznam balíčků se nachází v registrech pod
klíčem HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Jakmile balíček uživatele ověří,
pokračuje proces Winlogon v přihlašovací operaci autentizovaného uživatele. Pokud žádný
z balíčků neoznámí úspěšné ověření, přihlašovací proces se přeruší a uživateli je vypsána
příslušné chybové hlášení.
Autentizační balíčky se používají dva: Kerberos a MSV1_0. Výchozím balíčkem na
samostatném systému Windows je balíček MSV1_0 (\Windows\System32\Msv1_0.dll).
Proces Lsass využívá MSV1_0 i na členských počítačích domény, které mají systém starší
než Windows 2000, a na počítačích, které nejsou schopny po autentizaci lokalizovat
doménový řadič. Do této kategorie spadají například přenosné počítače dočasně odpojené ze
sítě. Autentizační balíček Kerberos (\Windows\System32\Kerberos.dll) se používá na
počítačích, které jsou členy domény Windows. Kerberos pro Windows ve spolupráci s se
službou Kerberos běžící na doménovém řadiči podporuje protokol Kerberos verze 5, revize 6.
Uživatel je ověřen a pokračujeme v startu systému. Winlogon vyhledá v registru hodnotu
HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Userinit a vytvoří
proces, který spustí vše, co je obsahem tohoto řetězce. Hodnota může obsahovat několik
programů typu .exe oddělených čárkami. Výchozí hodnotou je program Userinit.exe, který
zavádí uživatelský profil, a vytvoří proces, který spustí to, co je obsahem hodnoty
25
HKCU\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Shell, pokud tato
hodnota existuje. Ve výchozím nastavení hodnota neexistuje a Userinit.exe spouští to, co je
obsahem hodnoty HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\
Shell, což je program Explorer.exe. Po splnění tohoto úkolu program Userinit.exe končí (což
je také důvod, proč není u procesu Explorer.exe nikdy vidět žádný mateřský proces).
Obrázek 5.3.: Přihlašování uživatele
Poté, co se uživatel přihlásí se aktualní stav se uloží jako „Last known good configuration“,
můžeme říct, že je start systému úspěšný a hotový. Je aplikována user a computer policy a
startují programy, dávky a nástroje z různých míst, např:
HKCU\Software\Policies\Microsoft\Windows\System\Scripts
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\WindowsNT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
programy v C:\Winnt\Profiles\All Users\Start Menu\Programs\StartUp
Obrázek 5.4.: Nastartováno
26
6.0 Proč Windows padají a co je to BSOD
BSOD (Blue screen of death ) neboli „modrá obrazovka smrti“ se objeví přesně ve chvíli, kdy
už se systém dostal do takového stavu, že nemůže dál pokračovat, neuložená data jsou ztracena a
počítač musí být restartován. (Jedinou vyjímkou je BSOD po vyjmutí média, ze kterého systém
právě četl nebo zpracovával data. Po vrácení média nám obrazovka ve většině případů zmizí.)
Obrázek 6.1.: BSOD
Pokud takovou obrazovku vidíte poprvé, restartujte počítač. S největší pravděpodobností opět
nastartuje normálně a můžete pokračovat v práci. Pokud se však objevuje často, nebo po restartu
opakovaně, je potřeba situaci řešit.
Modré obrazovky existují už od verze Windows 2.0 a až na pár drobností jako je například
font se nemění. Jejich účelem je chránit jádro systému před poškozením a informovat uživatele o
tom, že nastala tak vážná chyba, že práce systému byla přerušena. Každá "modrá smrt" by nám
měla napovědět co se stalo a to pomocí chybových kódů, které vypíše na obrayovku a dump
souborů, do kterých ukládá informace o systému v době pádu. I když stále přibývá
administrátorů, kteří se zabývají analýzou těchto dump souborů, je pořád mnoho takových, co
celý proces prohlásí za zbytečný nebo příliš složitý a nedělají nic. Je to škoda, protože analýza
má cekem velkou úspěšnost a šikovný správce najde zdroj problému u 4 z 5ti analýz. Co ale stojí
za většinou těchto chybových stavů?
Odborníci a firma Microsoft se shodují, že za 70% případů mohou ovladače. Instalace nových
zařízení, upgrade stávajících ovladačů, ale i aktualizace systému, pokud má za úkol aktualizovat
nějaké ovladače. Architektura systému Windows NT/2000/XP a Vista totiž může za to, že jsou
všechny aplikace naprosto izolované od jádra systému a jejich špatný kód nebo pád nemůže
poškodit stabilitu systému. Bohužel jedna z částí systému, pro které tohle omezení neplatí jsou
ovladače zařízení. Ty mají přístup ke všem částem systému a pokud je ovladač špatně napsán,
poškodí běh jádra systému, je zavolána funkce KeBugCeckEx a ta je zodpovědná za vykreslení
modré obrazovky a zobrazení příslušného chybového kódu.
27
Mezi další příčiny patří viry a bugy 15% a poslední větší skupinou jsou chyby hardware 10%.
Chyby přímo v kódu systému z dílny Microsoftu mají 5%. Ze zkušenosti mohu říct, že pokud
jsem někdy analyzovala dump soubory, tak z toho vyšly vždy jen špatné ovladače nebo chybný
hardware (RAM paměti nebo pevný disk).
Chybová zpráva „Stop“ obsahuje kód chyby a její symbolický název, např.:
STATUS_IMAGE_CHECKSUM_MISMATCH . Podíváme se na ty nejčastější trochu blíže:
IRQL_NOT_LESS_OR_EQUAL
Úplně nejčastější. Objevuje se po instalaci špatného ovladače, po instalaci nového sw nebo hw.
INACCESSIBLE_BOOT_DEVICE
Systém nemůže najít zařízení ze kterého má startovat (vadný disk, chybějící startovací soubory)
PAGE_FAULT_IN_NONPAGED_AREA
Data která se snažíte zpracovat (už) nejsou v paměti, program se snaží zapsat kam nemá.
DRIVER_POWER_STATE_FAILURE
Potíže s ovladačem při startu, vypínání nebo hibernaci.
UNKNOWN_HARD_ERROR
Systému se nepodařilo načíst část registrů s informacemi o hardware
STATUS_IMAGE_CHECKSUM_MISMATCH
Nepřístupný disk, souborový systém a patří sem i poškozený page file.
Systém je standartně nastaven tak, že se snaží zapisovat informace o pádu pro ty, kteří chtějí
zkoumat příčinu. Jak to máte nastaveno zjistíte, když otevřete Control panels, systém, záložku
advanced a tlačítko settings u části nazvané Startup and recovery.
Existují tři možnsti výpisů dump souborů:
 kompletní (full memory dump)
 výpis paměti(kernel memory dump)
 minimální (small memory dump nebo minidump).
Z minimálního výpisu se moc informací nedozvíme a používá se v případě, že máme málo
místa na pevném disku. Velikost je 64kb pro 32-bitové systémy, 128kb pro 64-bitové systémy,
maximálně 2 MB informací. Kernel dump uloží celý právě v tu chvíli používaný obsah RAM
paměti, což může být kolem 100 MB pro počítače s méně jak 2 GB RAM a kompletní se
pohybuje ve stovkách MB. Mezi ukládaná data kompletního výpisu patří:





Chybová Stop zpráva a její parametry
Seznam načtených ovladačů
Informace o procesech a vláknech procesů, obraz paměti procesů
Obsah registrů pro vlákna
Obsah zísobníku
28
Každému vyhovuje něco jiného a volba je na uživateli. Vytvořený soubor na disku bude
v rootu a jeho přípona .dmp.
Systém vytváří a zapisuje .dmp soubor na disk až po tom, co se restartuje. Je to schválně, ve
chvíli problémů je naprogramován tak, aby použil minimum ovladačů co jsou potřeba. Kam
informace uloží, když se .dmp soubor objeví až po restartu počítače? Cílem je page file
(stránkovací soubor na disku) Page file je v tuhle chvíli otevřený a používaný (pokud je systém
nastaven, aby ho používal a to je 99.9% ) a tak je teoreticky nejvhodnějším místem. Umístění jde
změnit pomocí aplikace jménem Dr. Watson.
6. 1 Analýza dump souborů
Existují tři možnosti, jak získat informace o tom co se s naším systémem stalo.
První a nejméně náročná z nich je web oca.microsoft.com. (OCA je zkratka pro Online Crash
Analysis ) Po tom, co systém opět restartuje, objeví se nám na ploše okno s dotazem o odeslání
informací do firmy Microsoft, OCA týmu k analýze. Většinou to bývá jen minidump a žádné
soukromé informace navíc se neodesílají. Microsoft by nám pak měl za normální situace poslat
nějaké výsledky zpět, ale jak už bylo napsáno výše, minidump nám toho zrovna moc neprozradí,
a tak ta snaha firmě Microsoft často nevychází nebo nám zašlou jen obecnou radu.
Druhou možností, je opsání si chybového kódu z modré obrazovky a vyhledání příslušného
článku v Knowledge base firmy Microsoft nebo v TechNetu. (Tuto možnost využívají hlavně
lidé, kteří se bojí odesílaných informací, a na podrobnější analýzu sami se necítí) Tenhle způsob
nám také nedá moc práce, ale ani nemusí přinést výsledky, protože když zjistíme, že to opravdu
byl ovladač, pořád neříkají jaký. Pokud jsme zrovna neinstalovali nové zařízení, jsme opět na
začátku hledání.
Knowledge base http://support.microsoft.com
TechNet http://www.microsoft.com/cze/technet nebo http://technet.microsoft.com/en-gb
Třetí a nejlepší možnost je program program Windbg. Program je zdarma ke stažení na
internetové adrese http://www.microsoft.com/whdc/ddk/debugging a podporuje systémy
Windows NT 4, Windows 2000, Windows XP a Server 2003 všech verzí. Vždy je dobré před
analýzou zkontrolovat případné aktualizace a stáhnout soubory symbolů, které obsahují
nejrůznější funkce, proměné a jména, která jsou pro každou verzi systému jiná. Soubory
symbolů jsou samorozbalovací a patří do lokace \windows\symbols, ale Windbg je umí
aktualizovat i automaticky. Zastaralé nebo špatné soubory symbolů mohou místo srozumitelného
textu vypsat na obrazovku hromadu nečitelného strojového kódu.
29
Obrázek 6.2.: Program Windbg
Program pracuje v textovém režimu na příkazy a po tom, co ho spustíme a otevřeme daný
.dmp soubor, první příkaz, který napíšeme bude nejspíše
!analyze
který nám zobrazí základní informace o systému před pádem nebo
!analyze –v
který nám zobrazí informace v trošku detailnější podobě.
Další užitečné příkazy jsou:





!thread tid – prozkoumat aktuální thread
!process 0 0 – seznam všech procesů
!lm kv – seznam zavedených ovladačů
!vm – obsazení paměti
!help – nápověda příkazů
Úplný seznam příkazů přikládám na konci dokumentu ve zdrojích jako link.
30
Jak vypadá takový minidump?
Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [c:\windows\minidump\Mini120107-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*c:\symboly*http://msdl.microsoft.com/download/symbols
Executable search path is: c:\windows\i386
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Sat Dec 1 17:20:26.562 2007 (GMT+1)
System Uptime: 0 days 0:42:03.191
Loading Kernel Symbols
Loading unloaded module list
Unable to load image RtkHDAud.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for RtkHDAud.sys
*** ERROR: Module load completed but symbols could not be loaded for RtkHDAud.sys
**************************************************************************
***
*
*
*
Bugcheck Analysis
*
*
*
**************************************************************************
***
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, b8541bee, b555071c, 0}
Probably caused by : RtkHDAud.sys ( RtkHDAud+148bee )
Followup: MachineOwner
1: kd> !analyze -v
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008E)
This is a very common bugcheck. Usually the exception address pinpoints the
driver/function that caused the problem. Always note this address as well as the link date of
the driver/image that contains this address. Some common problems are exception code
0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was
booted /NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...If this happens, make sure a debugger gets
31
connected, and the system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: b8541bee, The address that the exception occurred at
Arg3: b555071c, Trap Frame
Arg4: 00000000
Debugging Details:
-----------------EXCEPTION_CODE: (NTSTATUS) 0xc0000005
FAULTING_IP: RtkHDAud+148bee
b8541bee 8982bc000000 mov dword ptr [edx+0BCh],eax
TRAP_FRAME: b555071c -- (.trap 0xffffffffb555071c)
ErrCode = 00000002
eax=00000001 ebx=863b5c30 ecx=863c2028 edx=00000000 esi=b85e1d08 edi=b85e1d08
eip=b8541bee esp=b5550790 ebp=b5550794 iopl=0
nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
RtkHDAud+0x148bee: b8541bee 8982bc000000 mov dword ptr [edx+0BCh],eax
ds:0023:000000bc=???????? Resetting default scope
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: war3.exe
LAST_CONTROL_TRANSFER: from b8514e6a to b8541bee
STACK_TEXT:
b5550794 b8514e6a 00000000 864cdab8 863b5c30 RtkHDAud+0x148bee
b55509fc b989102c 863b5c30 0000000c 864e3008 RtkHDAud+0x11be6a
b5550a14 b989111c 864e3008 864cdab8 e19bfcac portcls!PcDispatchProperty+0x12e
b5550aa0 b9cb0ec9 864e3008 0000000c e19bfcac ks!KspPropertyHandler+0x616
b5550ac4 b988f1bd 864e3008 0000000c e19bfc20 ks!KsPropertyHandler+0x19
b5550b0c b988f148 864cda38 898df5d8 864e3008 portcls!CPortPinWaveCyclic
b5550b24 b9cb0f0f 898df5d8 864e3008 b5550b78 portcls!DispatchDeviceIoControl+0x44
b5550b34 b9896b75 898df5d8 864e3008 898df690 ks!KsDispatchIrp+0x126
b5550b48 b9896dd8 898df5d8 864e3008 b87c108e portcls!KsoDispatchIrp+0x40
b5550b78 804e13d9 898df5d8 00000004 864e3008 RtkHDAud+0x3c808e
b5550b88 b594c774 e1372758 00000000 864e3008 nt!IopfCallDriver+0x31
b5550bd8 b594f2a2 864e3008 863b4960 e11e5658 sysaudio!ForwardIrpNode+0x1b2
b5550c30 b9cb0f85 897669b8 864e3008 b5550c64 sysaudio!CPinInstance
b5550c40 804e13d9 897669b8 864e3008 806ff410 ks!DispatchDeviceIoControl+0x28
b5550c50 8056f50b 864e3150 863dd838 864e3008 nt!IopfCallDriver+0x31
b5550c64 80580fc1 897669b8 864e3008 863dd838 nt!IopSynchronousServiceTail+0x60
b5550d00 80586eee 00002a94 00002348 00000000 nt!IopXxxControlFile+0x5ef
b5550d34 804dd99f 00002a94 00002348 00000000 nt!NtDeviceIoControlFile+0x2a
b5550d34 7c90eb94 00002a94 00002348 00000000 nt!KiFastCallEntry+0xfc
0012e800 00000000 00000000 00000000 00000000 0x7c90eb94
32
STACK_COMMAND: kb
FOLLOWUP_IP:
RtkHDAud+148bee
b8541bee 8982bc000000 mov
dword ptr [edx+0BCh],eax
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: RtkHDAud+148bee
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: RtkHDAud
IMAGE_NAME: RtkHDAud.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 467ba10a
FAILURE_BUCKET_ID: 0x8E_RtkHDAud+148bee
BUCKET_ID: 0x8E_RtkHDAud+148bee
Followup: MachineOwner
Některé informace jsou užitečné a čitelné, jiné obsahují jen adresy v paměti nebo
nesrozumitelný kód a moc nám toho neprozradí. Pomocí nejrůznějších příkazů, jako již výše
zmíněný !analyze –v, se snažíme nalézt příčinu. Minidump se pokouší vyhodnotit situaci sám
hned na začátku, v tomto případě řádkem:
Probably caused by : RtkHDAud.sys
Pro naší situaci tedy předpokládejme, že za pád systému opravdu může RtkHDAud.sys a
že známe STOP kód chybového hlášení: STOP 0x0000008E. Pomocí Internetových
vyhledávačů, webových stránek Microsoftu nebo u odborníků pak můžeme dohledat více
informací a zjistit jak celý stav napravit. V našem případě chybu popisují tyto stránky:
http://support.microsoft.com/kb/315335
http://www.short-media.com/forum/showthread.php?t=50966
A říkají, že jeden nebo více modulů naší RAM paměti je chybný nebo je složení modulů
nekompatibilní se systémem Windows XP. Řešením je otestovat paměťové moduly, najít
vadný a vyměnit jej, případně vyzkoušet jiný slot pro modul nebo navýšit paměť, pokud je
pro systém XP nedostačující. Pokusíme se tedy udělat co doporučují a znovu nastartujeme
systém tentokrát snad už v normálním režimu.
Bohužel, tak jednoduché to vždycky není a může se stát, že nám tento postup nepomůže.
Může se stát, že nám příští pád systému na tom samém místě vygeneruje úplně jiný dump
soubor. Může se stát, že nám dump nepomůže vůbec... Analýza dump souborů je podle mého
názoru tak trošku detektivní práce a ještě jednou připomínám, že celý proces je nutný až ve
chvíli, kdy nám systém padá opakovaně v jednu konkrétní chvíli nebo nestartuje vůbec.
33
7.0 Závěr
Díky této práci se může čtenář detailněji seznámit s celým procesem startu systému
Windows 2000 nebo XP a alespoň z části ovlivnit jeho průběh nebo napravit běžné chybové
stavy. Celý proces je opravdu složitý, nicméně pokud víme, ve které fázi co upravit nebo jaký
nástroj k tomu použít, můžeme získat více výkonu, rychlejší start nebo stabilitu. Během startu
systému může dojít k velkému množství chyb, ale pokud víme co je způsobuje nebo jim
dokážeme předejít, náprava může být otázkou několika minut. Jsem si vědoma toho, že době
psaní této práce už existuje nový systém Windows Vista a jeho proces startu se může v
některých fázích lišit, nicméně i tak jsem přesvědčena, že jsou informace v této práci ještě
stále užitečné.
34
8.0 Přílohy
Příloha 1 - Seznam všech souborů potřebných pro start systému
NTLDR
Skrytý systémový soubor, který řídí start systému Windows 200/XP
Boot.ini
Skrytý a systémový soubor. Informace v tomto souboru slouží k výběru systémů při startu
počítače. Soubor obsahuje čitelný text a je možné ho editovat.
Bootsect.dos
Skrytý soubor, který se používá při startu systému u výběru jiného systému než Windows
2000/XP. Obsahuje informace o podobě pevného disku před instalací Windows 2000/XP.
Ntdetect.com
Skrytý spustitelný soubor, který shromažďuje informace o používaném hardware a vytváří o
něm detailní seznam. Seznam předává souboru NTLDR, který jej zapisuje do registrů.
Hiberfil.sys
Skrytý soubor, který slouží pro hibernaci systému. (Uvedení počítače do zvláštního režimu
spánku, kdy po jeho opětovném spuštění nastartuje do stavu, v jakém byl těsně před
vypnutím) V souboru je uložen obsah RAM paměti před hibernací.
Ntbootdd.sys
Skrytý a nepřepsatelný soubor, který je potřeba při startu systému z disků SCSI.
Ntoskrnl.exe
Hlavní a jediný soubor s mini-jádrem systému Windows 2000/XP
Hal.dll
Soubor obsahující detailní informace o hardware a jeho přerušení.
Csrss.exe
Csrss znamená client/server run-time subsystem (subsystém pro běh prostředí klient/server),
který zodpovídá za okna konzolí, vytváření a odstraňování podprocesů a některé části
16bitového virtuálního prostředí systému MS-DOS.
35
Internat.exe
Proces Internat.exe je spouštěn při spuštění systému a načítá různá národní prostředí určená
uživatelem, zobrazuje na hlavním panelu ikonu "CZ" a umožňuje uživateli přepínat mezi
národními prostředími.
Lsass.exe
Tento proces představuje místní server ověřování zabezpečení a generuje proces zodpovědný
za ověřování uživatelů pro službu Winlogon..
Smss.exe
Tento proces představuje subsystém správce relace, který zodpovídá za spouštění
uživatelských relací. Je zodpovědný za spouštění procesů Winlogon a Win32, Csrss.exe a
nastavování systémových proměnných.
Explorer.exe
Tento proces představuje uživatelské prostředí. Explorer.exe je možné zastavit nebo
restartovat v programu Správce úloh i během práce s počítačem, pád systému většinou
nezpůsobí.
Pagefile.sys
Stránkovací soubor systému. Používá se jako virtuální paměť ve chvíli, kdy fyzická RAM
nestačí. Rezervuje si určité místo na pevném disku. (Doporučená velikost je dvojnásobek
fyzické paměti)
Spoolsv.exe
Zařazovací služba (Spooler Service) zodpovídá za správu zařazování tiskových a faxových
úloh.
Svchost.exe
Toto je obecný proces sloužící jako hostitel dalších procesů spouštěných z knihoven DLL.
Proto je běžné, že běží více než jedna instance tohoto procesu.
Services
Tento proces představuje Správce řízení služeb, který je zodpovědný za spouštění,
zastavování a interakci se systémovými službami.
System
systémový soubor konfiguračního nastavení na tomto počítači. Řídí sled natahování
jednotlivých ovladačů a služeb.
Winlogon.exe
Tento proces je zodpovědný za správu uživatelských přihlášení a odhlášení.
Winmgmt.exe
Proces Winmgmt.exe je klíčovou součástí správy klientů v systému Windows 2000. Tento
proces je spouštěn při připojení první klientské aplikace nebo trvale tehdy, pokud aplikace pro
správu požadují jeho služby.
36
9.0 Seznam použité literatury, zdroje a linky
9.1. Seznam použité literatury a zdroje
Kniha Windows Internals, třetí vydání od autorů Mark E. Russinovich and David A. Solomon
https://www.microsoft.com/MSPress/books/6710.aspx
IT web LabMice
http://labmice.techtarget.com
IT web Admin XP
http://www.adminxp.cz
Materiály ze školení GOC7, Windows Internals
http://www.gopas.cz/DetailKurzu.aspx?IDKurzu=4031
9.2. Linky
Seznam zvukových signálů AMI BIOSu, Phoenixu a dalších z kapitoly 1
http://bioscentral.com/beepcodes/amibeep.htm
Bootovací diskety a CD k nejrůznějším Windows systémům z kapitoly 3, odstavce 1
http://www.bootdisk.com
Seznam příkazů pro nástroj Recovery Console z kapitoly 3, odstavce 1
http://hps.mallat.cz/view.php?cisloclanku=2004022501
Windows Live CD nebo Windows PE z kapitoly 3, odstavce 1
http://www.nu2.nu/pebuilder
http://www.nliteos.com/nlite.html
http://www.ubcd4win.com/contents.htm
Boot.ini popis a přepínače z kapitoly 3
http://www.adminxp.cz/windows2000/index.php?aid=46
http://support.microsoft.com/kb/833721
Web, který se zabývá podrobnou analýzou dump souborů a jednotlivými příkazy programu
Windbg z kapitoly 6
http://www.dumpanalysis.org/blog/
37