Aktualizace: 21.11.2008
Autor: Michal "Mitch" Pavlík
Boot Configuration Database
Jednou z nejvíce viditelných změn v procesu startu systému je absence souboru Boot.ini. Informace, které byly v tomto souboru
uloženy, jsou nyní v BCD. Jeden z důvodů zavedení této databáze bylo spojení dvou bootovacích architektur: Master Boot Record
(MBR) a Extensible Firmware Interface (EFI). MBR je obvykle používán na x86 a x64 systémech, zatímco EFI především na systémech
používající Itania (a plánuje se nasazení i na obyčejných desktopech). BCD odstiňuje firmware od systému a má proti Boot.ini
další výhody jako podporu Unicode.
BCD je uložen na disku ale windows je po nabootování načtou do registru, aby se k ní dalo přistupovat přes známé API. Na PC
je BCD v adresáři \Boot\Bcd systémového disku a na strojích s EFI pak na systémovém EFI oddílu. V registrech pak BCD naleznete
pod klíčem HKLM\Bcd00000000, ale v nedokumentovaném formátu, takže k editaci potřebujete nástroje jako
%SystemRoot%\System32\Bcdedit.exe. Rozhraní pro úpravu BCD obsahuje i Windows Management Instrumentation (je tedy možné
používat skripty) nebo můžete použít Windows System Configuration Utility (%SystemRoot%\System32\Msconfig.exe) k úpravě parametrů.
BCD rozděluje platformně nezávislé nastavení (boot menu timeout, výchozí OS....) od nastavení specifické pro OS (volby bootování,
cesta k zavaděči...). Na obrázku 1 je ukázka aplikace BCDEdit spuštěná bez parametrů. V části Windows Boot Manager je platformně
nezávislé nastavení a ve Windows Boot Loader nastavení specifické pro OS.
Toto nové schéma také dělí úlohy, které byly ve starších systémech obslouženy zavaděčem Ntldr, do dvou souborů: \BootMgr
a %SystemRoot%\System32\Winload.exe. BootMgr přečte BCD a zobrazí menu, zatímco Winload.exe má na starosati načtení operačního
systému. Standardní bootování probíhá tak, že Winload.exe načte potřebné ovladače a soubory jádra (včetně Ntoskrnl.exe) a
předá řízení systému. Pokud se systém probouzí z hibernace, spustí se %SystemRoot%\System32\Winresume.exe, který načte data
z hibernačního souboru do paměti a předá řízení.
BootMgr obsahuje podporu pre-boot aplikací. Windows Vista z nich má integrován předkonfigurovaný Windows Memory Diagnostic
(\Boot\Memtest.exe) který testuje paměť, ale není problém přidávat i aplikace třetích stran.
Obrázek 1 - Výpis programu Bcdedit
Startup Processes
Ve starších systémech nebyl vztah mezi různými aplikacemi intuitivní. Například při bootování, Interactive Logon Manager
(%SystemRoot%\System32\Winlogon.exe) spustil Local Security Authority Subsystem Service (Lsass.exe) a Service Control Manager
(Services.exe). Později Windows použily zásobník jmených prostorů (tzv. Session) aby izolovaly procesy běžící v jednotlivých
zalogovaných relacích. Při přihlášení do Session 0 (relace používaná systémovými procesy) mohlo vzniknout bezpečnostní riziko.
Napřklad když špatně napsaná služba běžící v Session 0 na konzoli zobrazí uživatelské rozhraní. To umožňí malwaru zaůtočit
na okno a získat administrátorská práva.
Aby se tomu předešlo, bylo několik systémových služeb ve Windows Vista předěláno. Session Manager (Smss.exe) je
stejně jako v předešlých systémech první proces běžící v user-mode, ale Windows Vista nově spouštějí ještě druhou instanci
ke konfiguraci Session 0. Tato instance je vyhrazena
pouze pro systémové procesy. Session Manager pro Session 0 spustí aplikace Windows Startup Application (Wininit.exe),
Windows Runtime Server Subsystem (Csrss.exe) pro Session 0 a pak se ukončí. Windows Startup Application pokračuje spuštěním
Service Control Manager-a, Local Security Authority Subsystem-u a nového procesu Local Session Manager-a (Lsm.exe), který
spravuje připojení terminálového serveru.
Když se uživatel zaloguje do systému, vytvoří Session Manager svojí druhou instanci, aby zkonfiguroval novou relaci. Tato
instance spustí v uživatelově relaci procesy Windows subsystem a Winlogon.
Obrázek 2 - Izolace služeb v Session 0
S touto architekturou jsou systémové procesy (a služby) v Session 0 izolovány. Pokud se služba běžící v Session 0 pokusí zobrazit uživatelské rozhraní, služba Interactive Services Detection (%SystemRoot%\System32\UI0Detect.exe) upozorní zalogovaného administrátora a klientovi zobrazí dialogové okno. Pokud uživatel zvolí "Show me the message", služba přepne do Windows service desktop, kde může uživatel používat grafické rozhraní a pak se vrátit zpět.
Credential Providers
V předchozích verzích Windows načetl proces Winlogon knihovnu Graphical Identification and Authentication (GINA, cesta je
uložena v registrech) pro zobrazení rozhraní, které uživatelovi umožní zalogování. Bohužel GINA má několik omezení zahnující
fakt, že může být pouze jedna a pro vývojáře třetích stran je těžké napsat kompletně vlastní rozhraní.
Windows Vista tak místo GINA používá novou architekturu nazvanou Credential Provider. Winlogon spustí oddělený proces
Logon User Interface Host (Logonui.exe), který načte credential provider-y. Jejich konfigurace je uložena v registru, klíč
Obrázek 3 - Zjednodušené schéma logování
Delayed-Autostart Services
Pokud jste se někdy zalogovali hned po startu systému, pravděpodobně jste nemohli okamžitě pracovat, protože Service Control
Manager musel spouštět množství služeb, které měly nastaveny automatické spuštění po startu a to vyžadovalo systémové zdroje.
Windows Vista přináší nový typ spouštění služeb - delayed automatic start (spožděné automatické spuštění), který mohou použít
služby, jenž nemusí být aktivní hned po startu systému.
Tyto služby Service Control Manager spouští až po všech službách s normálním typem automatického startu. Zároveň je priorita
inicializačního threadu nastavena na THREAD_PRIORITY_LOWEST. To mimojiné znamená že mají I/O prioritu na hodnotě Very Low.
Po dokončení inicializace jim Service Control Manager nastaví normální prioritu. Kombinace zpožděného spuštění a nízkých
priorit zkrátí dobu, po kterou je uživatel přihlášen, ale nemůže pracovat. Mnoho služeb jako Background Intelligent Transfer,
Windows Update Client a Windows Media Center tento typ spuštění využívají.
K zjištění typu spuštění (a jiných vlastností) služby můžete použít příkaz "sc".
Obrázek 4 - Výpis vlastností služby příkazem sc
Shutdown
Jeden z problémů, který trápil vývojáře služeb byl ten, že při ukončování systému mají služby na dokončení práce maximálně
20 sekund (výchozí nastavení). Starší systémy nemohly čekat až služby skončí, protože chybně napsaná služba mohla nechat
systém čekat do nekonečna. Některé služby ovšem potřebují více jak 20 sekund (například když musí uložit velké množství dat
na disk).
Windows Vista umožňuje službám vyžadovat tzv. pre-shutdown notification (oznámení před ukončením). Když se pak systém ukončuje,
Service Control Manager těmto službám nejprve pošle pre-shutdown notification a čeká až ukončí svou činnost. Pokud služby 3 minuty
neodpovídají, jsou ukončeny násilně. Když jsou všechny tyto služby ukončené (nebo vyprší timeout), Service Control Manager
pokračuje s ostatníma službama stejným stylem jako ve Windows XP. Pre-shutdown notification vyžadují například služby
Group Policy a Windows Update. Příkaz "sc" bohužel nezobrazí, zda služba vyžaduje pre-shutdown notification. K tomu
můžete použít aplikaci PsService ze Sysinternals.
Obrázek 5 - Výpis podrobnějších vlastností služby aplikací PsService
Již zmíněné služby Group Policy a Windows Update také využívají jiné vlastnosti a tou je shutdown ordering (pořadí ukončení). Některé služby jsou závislé na jiných službách, a proto je nutné je spouštět v určitém pořadí. Ale ve Windows Vista je možné služby v zadaném pořadí i ukončovat. Konfigurace pořadí je v registrech, klíč:
Mitch