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
