Jak startuje system Windows Vista?
Zawartość strony
Start komputera - wprowadzenie
Start komputera typu PC od lat osiemdziesiątych wygląda cały czas tak samo. Zmieniło się wprawdzie troszkę z nadejściem standardu ATX czy PCI, ale cały czas wszystko tak naprawdę zaczyna się od pierwszego kroku procesora.
Krok ten kierowany jest zawsze w tę samą stronę: pod adres FFFF:0000. Segmentowe adresowanie pamięci dostępne w trybie rzeczywistym procesorów x86 sprawia, że od adresu FFFF:0000 do końca dostępnej pamięci RAM jest tylko 16 bajtów. To niewiele, w związku z czym pod tym adresem znajduje się zwykle tylko instrukcja JMP kierująca procesor tam, gdzie naprawdę leży jego BIOS (tradycyjnie to F000:E05B).
BIOS jest programem jak każdy inny i procesor go krok po kroku wykonuje. W ramach tego programu robiony jest POST (Power On Self Test) i procesor sprawdza, czy komputer jest w miarę kompletny i sprawny. Testy te zależą od tego, w jaki sposób komputer został zresetowany, więc i taką informację BIOS oczywiście ma.
Jeżeli komputer wygląda na kompletny – BIOS nakazuje procesorowi poszukać kart zawierających własny BIOS i uruchomienie tych rozszerzeń. W tym celu „przeczesuje” obszar pamięci od C800:0000 do F000:000 i jak znajdzie sygnaturę 55AA – uruchamia to, co tam się znajduje. W obszarze tym swoje programy inicjujące mają na przykład karty rozszerzeń. Dzięki temu BIOS wie, jak obsłużyć daną kartę graficzną. Po prostu uruchamia jej kod i liczy, że to ona go swojej obsługi nauczy.
Po tym wszystkim BIOS wczytuje (przy pomocy INT 19h) pierwszy sektor z urządzenia uznanego jako startowe do pamięci pod adres 0000:7C00 i przekazuje tam sterowanie uznając, że jego rola się skończyła.
Jeżeli urządzeniem startowym jest dysk twardy – również wczytywany jest jego pierwszy sektor, czyli tak zwany MBR (Master Boot Record). Tak oto, jak tylko komputer skończy inicjować sprzęt, wykonuje program zapisany w MBR. Dlatego MBR jest tak ważny i dlatego mówiąc o starcie systemu operacyjnego, właśnie MBR uznaje się za początek.
Nowości w starcie Windows Vista
Sektor jak to sektor - tradycyjnie ma 512 bajtów, co wymaga od programistów dość zwięzłego podejścia, zwłaszcza, że ostatnie bajty zarezerwowane są na tablicę partycji.
I tu zaczyna się nowe. W największym skrócie można napisać, że w starszych systemach wyglądało to dalej tak, że MBR ładował boot sektor aktywnej partycji, ten z kolei ładował NTLDR, który włączał tryb chroniony procesora, odczytywał boot.ini, uruchamiał ntdetect.com, który sprawdzał konfigurację sprzętu, a na końcu NTLDR uruchamiał ntoskrnl.exe i jakoś to dalej szło.
W starszych systemach MBR mógł być dowolny pod warunkiem, że pozwalał na załadowanie boot rekordu z partycji systemowej. Co po drodze wyświetlał, gdzie sięgał, co inicjował, rozszyfrowywał lub uruchamiał – nie miało znaczenia. Jeżeli tylko na końcu załadował boot record i oddał mu sterowanie, to system pozwalał się uruchomić. MBR mógł pytać o wybór systemu (tak robi na przykład LILO), mógł aktywować ukryte partycje (na przykład Partition Magic), rozszyfrowywać fragment dysku (na przykład SafeBoot), czy uruchamiać specjalne aplikacje do odzyskiwania danych (na przykład ThinkVantage Rescue and Recovery).
W przypadku Windows Vista nie jest tak prosto. Choćby dlatego, że kod zapisany w MBR musi być zgodny ze specyfikacją TCG (Trustec Computing Group) aby bardzo ściśle współpracować z TPM.
Jeżeli ktoś koniecznie musi dodać własny kod i uruchamiać go przed startem systemu – powinien omijać MBR. Proces startu Windows Vista zapewnia wsparcie dla takiego kodu, jednak uruchamiany jest on inaczej. Zostanie to opisane w dalszej części artykułu.
Dla potrzeb artykułu założyć należy, że system uruchamiany jest z dysku twardego. Choć inne przypadki są obsługiwane(sieć, DVD, USB itp.), to jednak głębsze wnikanie w nie jest na tyle rzadko potrzebne, że dla jasności opisu sytuacje te nie zostaną tu omówione.
Master Boot Recorder
Ważne jest, aby zapamiętać, że MBR nie powinien być zmieniany. Prawdopodobnie niedługo pojawią się inne MBR pozwalające uruchomić Windows Vista, ale należy się na nie decydować tylko tam, gdzie jest to niezbędne i tam, gdzie twórca takiego MBR deklaruje, że wie co to jest Windows Vista i co z nim zrobić. W szczególności, niezgodne będą MBR pochodzące od poprzednich wersji systemów Windows. Niezależnie od zgodności z Windows Vista, należy mieć świadomość, że uruchomienie systemu to nie wszystko. Nawet, jeżeli to się uda z alternatywnym Master Boot Recordem to najprawdopodobniej olbrzymie kłopoty zaczną się przy szyfrowaniu (i rozszyfrowaniu) przy pomocy mechanizmów BitLocker.
Próbując uruchomić system, BIOS wczytał MBR i oddał mu sterowanie. MBR taki, mając bardzo niewiele miejsca na kod wykonywalny może wykonać tylko bardzo proste operacje. W przypadku Windows Vista, MBR identyfikuje partycję startową (boot) i wczytuje z niej NTFS boot code. NTFS boot code to takie niewielkie oszustwo. Teoretycznie, MBR powinien wczytać tylko pierwszy sektor partycji. Sektor taki ma 512 bajtów, a to może być za mało na wykonanie wszystkich operacji potrzebnych do uruchomienia systemu. Partycja zorganizowana jest jednak w taki sposób, że dane zapisywane są na niej od pierwszego sektora w cylindrze. Oznacza to, że nawet skoro boot record zajmuje zgodnie ze standardami tylko jeden sektor z cylindra, to pozostałe na pewno nie zostaną wykorzystane na dane. Dlatego bardzo dobrze nadają się one na zapisanie kodu, który może zostać wykonany w czasie startu systemu. Firma Microsoft oficjalnie informuje, że może tych sektorów używać dla swoich potrzeb i dlatego mimo, że istniały aplikacje „chowające” w nich jakieś dane, to od czasów systemów DOS nie jest to praktykowane. W rzeczywistości oznacza to rozszerzenie kodu ładującego z 512 bajtów do 8KB. A jak na kod w assemblerze to całkiem niemało i w praktyce zajęte jest tylko 9 sektorów.
Rolą tego, co zapisane jest w NTFS boot code jest załadowanie i uruchomienie bootmgr. Plik ten znajduje się na partycji startowej (boot) i ma około 500KB. To dopiero on tak naprawdę uruchamia system operacyjny, wykonując wcześniej parę ważnych operacji. Ponieważ kod zapisany w NTFS boot code jest z konieczności mocno ograniczony, to nie umie on na przykład sięgnąć gdziekolwiek poza główny katalog dysku, nie umie nic zapisać na partycji NTFS i co ważne – nie umie poradzić sobie z kompresją NTFS. Dlatego skompresowanie pliku bootmgr uniemożliwi start systemu. Wbrew pozorom skompresowanie takie nie jest operacją prostą i system dość skutecznie broni się przed uniemożliwieniem mu pracy. Z powodu prostoty NTFS boot code nie jest również obsługiwane żadne szyfrowanie pliku bootmgr. To właśnie z tego wynika potrzeba rozkładania chronionych BitLockerem danych na dwie partycje. Bootmgr musi być maksymalnie łatwy do odczytania, ponieważ używany jest do tego bardzo uproszczony kod.
Po załadowaniu bootmgr, do niego właśnie przekazywane jest wykonanie i od tej pory to bootmgr odpowiada za to, co się dzieje dalej.
Plik bootmgr
Bootmgr potrafi już wykonać dość dużo operacji. Jest on z założenia niezależny od systemu operacyjnego i równie chętnie uruchomi Windows Vista, jak i Windows 2000 czy system Linux. Jedyne, co bootmgr musi wiedzieć, to informacje na temat tego, co ma do dyspozycji. W starszych systemach, w roli repozytorium informacji o dostępnych opcjach, występował plik boot.ini. Plik ten zawierał proste informacje tekstowe i był równie łatwy do świadomej edycji jak i nierozważnego popsucia. W przypadku Windows Vista zrezygnowano z prostego pliku tekstowego, zastępując go strukturą BCD. W środku BCD zorganizowane jest w hierarchiczną, drzewiastą strukturę i zapisywane w formie nie odbiegającej znacząco od danych przechowywanych w rejestrze systemu. BCD jest źródłem danych dla bootmgr i właśnie z niego odczytywane są informacje na temat tego jak ma się zachować komputer w czasie uruchamiania systemu. Ponieważ (w przeciwieństwie do MBR czy NTFS boot code) to, jak ma się zachować bootmgr, może mieć znaczenie dla końcowego użytkownika, struktury BCD dają się w miarę prosto edytować i przeglądać. Zostanie to omówione w dalszej części artykułu.
Analizując szczegółowo zachowanie bootmgr, stwierdzić można, że inicjuje on kolejno: GDT (Global Descriptor Table), IDT (Interrupt Dispatch Table), pamięć, firmware, TPM, systemy plików, magistralę PCI, debugger, kartę graficzną, uzyskuje dostęp do własnej sekcji .rsrc i w końcu inicjuje sieć.
Wszystko to po to, żeby móc odczytać BCD. Jeżeli w BCD znajduje się więcej niż jedna pozycja, to bootmgr wyświetli użytkownikowi menu pozwalające na wybranie systemu do uruchomienia. Jeżeli pozycja jest tylko jedna – wybór dokonywany jest automatycznie.
Po dokonaniu wyboru bootmgr wczytuje wszystkie parametry wybranej pozycji z BCD, wśród których znajduje się między innymi położenie i nazwa programu, który odpowiadać będzie od tej pory za uruchomienie systemu. W przypadku Windows Vista jest to \Windows\system32\Winload.exe z partycji systemowej. O ile bootmgr można uznać za niezależny od systemu operacyjnego i zdolny do uruchomienia każdego systemu, o tyle Winload.exe jest już zdecydowanie fragmentem Windows Vista.
Warto zwrócić uwagę, że bootmgr potrafi zrozumieć i rozszyfrować dysk systemowy chroniony mechanizmami BitLocker. Jest to konieczne, ponieważ w standardowym scenariuszu plik Winload.exe jest zaszyfrowany. Aby przekazać do niego wykonanie dalszej części kodu, wszystkie operacje związane z pozyskaniem „key protectors” i otrzymaniem klucza VEK muszą być wykonane wcześniej. W efekcie to na bootmgr spoczywa obowiązek poproszenia użytkownika o klucz, pin, pamięć flash itp. Bootmgr potrafi porozumieć się z TPM, sprawdzić czy podany klucz jest prawidłowy i wykonać wszystkie operacje związane z rozszyfrowaniem dysków. Do pamięci ładowany jest plik w jawnej postaci i przez funkcję OslpMain przejmuje on kontrolę nad dalszymi losami systemu.
Co potrafi plik Winload.exe
Winload.exe po zainicjowaniu tych samych elementów, które inicjował bootmgr, wykonuje kilka bardzo ciekawych operacji:
| • | Po pierwsze, jeżeli włączono opcję logowania, zapisuje wszystkie swoje kroki do /Boot/boostat.dat na partycji startowej. Może się to przydać do śledzenia poważnych problemów ze startem systemu. |
| • | Po drugie: inicjuje wyświetlanie grafiki na ekranie. |
| • | Po trzecie: odszukuje w samym sobie zasoby (resource) osloader.xml i pobiera z nich informację na temat tego, co ma wyświetlić na ekranie. |
| • | Po czwarte: wyświetla startowy obrazek na ekranie. |
I tu otwiera się ogromne pole do popisu dla rozmaitego rodzaju amatorów „tuningu optycznego”. Osloader.xml może zawierać własne teksty i własne grafiki bardziej świadomego użytkownika. Nie jest to zupełnie trywialne, ponieważ jest to fragment winload.exe. Zasób taki nie jest bardzo trudny do zmienienia dedykowanymi narzędziami, za to pojawi się poważny problem, ponieważ plik jest podpisany cyfrowo. Zmiana choćby jednego bajta, nawet jak dotyczy to tylko obrazka na ekranie sprawi, że plik nie zostanie uznany za oryginalny i system nie uruchomi się. Mimo tego, można podmienić grafikę startową korzystając z ciekawej funkcjonalności systemu. Chodzi o to, że zasoby (bez kodu wykonywalnego) mogą znajdować się w dodatkowym pliku. Ma to na celu ułatwienie tworzenia nowych wersji językowych. Można zachować oryginalny Winload.exe, wskazując mu jednak własny plik, jako źródło napisów i obrazów. W tym celu należy zapisać oryginalne zasoby z sekcji 1 w RCData do nowego pliku o nazwie winload.wim, wyekstrahować grafikę microsoftowym programem ImageX, przerobić po swojemu i zapisać nową wersję winload.wim. Następnie należy znaleźć winload.exe.mui i oryginalną sekcję RCData\1\1033 (w polskiej wersji systemu 1045) zastąpić tą z pliku winload.wim. W przypadku zmiany tekstu, należy modyfikować sekcję 23\OSLOADER.XML\osload-status. Parę minut i system wygląda zupełnie inaczej niż ta sama wersja u kolegi.
Jako, że wyświetlenie tła nie jest ani podstawowym ani najważniejszym zadaniem, Winload.exe kontynuuje pracę wywołując funkcję BlDeviceOpen i tworząc strukturę LOADER_PARAMETER_BLOCK. Zapisane są w niej wskaźniki do najważniejszych danych na temat konfiguracji sprzętu i systemu. Następnie Winload.exe wyszukuje dostępne dyski, po czym ładuje gałąź rejestru HKEY_LOCAL_MACHINE.
Po załadowaniu rejestru, następuje sprawdzenie integralności systemu. Najpierw sprawdzane jest działanie funkcji SHA1 i PKCS1 a następnie przy ich użyciu weryfikowany jest sam Winload.exe. Ponieważ zastosowanie debuggera wpływa na wynik tego sprawdzenia, jeżeli debugger jest aktywny, Winload.exe prosi użytkownika o potwierdzenie, że wszystko jest OK i że użytkownik wie, co robi.
Po sprawdzeniu integralności Winload.exe ładuje do pamięci jądro systemu czyli ntoskrnl.exe oraz hal.dll ale jeszcze nie przekazuje im kontroli. Najpierw muszą zostać załadowane potrzebne (opisane w załadowanej już gałęzi HKLM) sterowniki trybu boot. Domyślnie, Windows Vista sprawdza (opisanym powyżej algorytmem) podpisy cyfrowe ładowanych sterowników, jednak w przypadku działania debuggera Winload.exe powiadamia o niezgodności podpisu nie blokując startu systemu. Dla kilkunastu najważniejszych dla bezpieczeństwa sterowników weryfikacja musi przebiec poprawnie, niezależnie do tego, czy debugger jest aktywny, czy nie.
Po załadowaniu sterowników ładowane są pliki wersji językowych (NLS), wyświetlany jest pasek postępu, wczytywane są parametry zgodności aplikacji, parametry tabel ACPI oraz plik errata.inf zawierający informacje o niepoprawnie wykrywanych urządzeniach PnP oraz PCI.
Po udanym zakończeniu tych działań, Winload.exe zapisuje plik z logami, kończy zadania związane z obsługą mechanizmów BitLocker i przekazuje do załadowanego właśnie jądra systemu kontrolę. Uruchamiana jest (tak samo jak w poprzednich systemach) funkcja KiSystemStartup i od tej pory można powiedzieć, że działa już Windows Vista.
Repozytorium informacji BCD
Wracając do procedury startu, skupić się należy na hasłowo dotąd wspomnianym BCD. Jest to repozytorium informacji, do którego sięga bootmgr zanim odda sterowanie do Winload.exe. Można powiedzieć więcej: główną rolą bootmgr jest odczytanie BCD i uruchomienie tego, co mu BCD rozkaże. W normalnych warunkach jest to Winload.exe, jednak prosto można zmienić to zachowanie. W skrócie stwierdzić można, że BCD jest godnym Windows Vista następcą pliku boot.ini.
Aby samodzielnie grzebać w BCD należy mieć prawa administratora. Ponieważ najlepsze narzędzia obsługiwane są z commandline – do takich operacji należy uruchomić cmd.exe z podniesionymi uprawnieniami. Należy również zdawać sobie sprawę, że nawet drobny błąd w danych BCD sprawi, że system nie uruchomi się. Z tego powodu, eksperymenty na BCD nie powinny być wykonywane na produkcyjnym systemie.
Architektura BCD składa się z trzech poziomów:
1. | BCD Store, |
2. | BCD Objects oraz |
3. | BCD Elements. |
BCD Store jest jednostką najwyższego poziomu. W praktyce najczęściej BCD Store składa się wyłącznie z System BCD Store i jest równoważne całemu BCD. Fizycznie, BCD Store jest zestawem plików o formacie zgodnym z formatem gałęzi rejestru. Pliki BCD Store zapisane są w katalogu \boot partycji startowej. System BCD Store zawiera informacje o zainstalowanych systemach operacyjnych oraz o aplikacjach, które mogą być uruchamiane podczas startu systemu.
Opcjonalnie można dodać inne BCD Store niż systemowy, co może być użyteczne na przykład do uruchamiania specjalnych aplikacji, służących do wykonywania kopii zapasowych czy tworzenia obrazu dysku systemowego. Jeżeli nazwa BCD Store nie jest jednoznacznie wyspecyfikowana, każde odwołanie domyślnie odnosi się do System BCD Store. Dotyczy to wszystkich narzędzi używanych do zarządzania BCD.
BCD Store zawiera obiekty BCD Objects. Ich maksymalna ilość nie jest ograniczona i zazwyczaj w skład BCD Store wchodzi obiekt Windows Boot Manager oraz jeden lub wiele obiektów Windows Boot Loader. Przeprowadzone na potrzeby niniejszego artykułu testy objęły między innymi konfigurację zawierającą wiele (kilka tysięcy) wpisów typu Boot Loader.
Doświadczenia pozwoliły na określenie, że pojedynczy wpis w BCD ma około 3KB. Choć tak duża ilość wpisów zauważalnie spowalnia uruchomienie systemu, to jednak całość sprawowała się bez zarzutu do momentu przekroczenia 5000 wpisów. Przy takiej ilości próba uruchomienia kończyła się błędem 0xC0000017. Naprawienie tego problemu możliwe jest z konsoli odzyskiwania, jednak w praktyce może być dość uciążliwe i czasochłonne.
Windows Boot Loader ma za zadanie załadować system operacyjny, czyli w praktyce uruchomić Winload.exe. Każdy zainstalowany system Windows Vista (i Windows 2008) ma swój wpis typu Windows Boot Loader i w nim zapisane informacje o położeniu pliku Winload.exe, który ma wykonać zdefiniowane dla niego zadania. Ponadto wpis typu Windows Boot Loader zawiera informacje o szczególnych parametrach uruchomienia, które zostaną omówione w dalszej części dokumentu.
Zawarty w BCD Store obiekt Windows Boot Manager (tylko jeden) ułatwia mechanizmom bootmgr decyzję, kiedy i jaki obiekt Windows Boot Loader wybrać. W szczególności, w Windows Boot Manager zapisane są informacje na temat kolejności wyświetlania wpisów na liście systemów do wyboru, informację na temat tego, jaki czas bootmgr oczekiwać będzie na decyzję użytkownika oraz dane na temat tego, który system uruchomić, jeżeli w zadanym czasie użytkownik nie może się zdecydować.
Inne typy obiektów, które czasem spotkać można w BCD Store to obiekt Windows ntldr oraz obiekty dotyczące specjalnych aplikacji.
Windows Ntldr jest specjalnym obiektem wskazującym bootmgr gdzie leży plik ntldr. Plik taki odpowiadał za załadowanie starszych wersji systemu. Stworzenie wpisu Windows Ntldr umożliwia na przykład dual boot pomiędzy Windows Vista a WindowsXP. Można to zrobić ręcznie, a można zdać się na program instalacyjny Windows, pamiętając jednak, że automatyczne rozwiązanie zadziała tylko wtedy, kiedy najpierw zostanie zainstalowany WindowsXP a dopiero po nim Windows Vista.
Ostatnim typem obiektu typu BCD Object jest obiekt aplikacji. Obiekt taki pozwala na uruchomienie dowolnej aplikacji zamiast uruchomienia systemu. Może to być program do backupu, aplikacja defragmentująca dyski twarde, program dający dostęp offline do plików itp. Przykładem aplikacji uruchamianej bezpośrednio przez bootmgr jest aplikacja testująca pamięć RAM. Aplikacja taka dostarczana jest z systemem Windows Vista i wydaje się, że największą jej wartością nie jest samo sprawdzenie pamięci, ale pokazanie, jak poprawnie należy używać funkcjonalności bootmgr. Można stworzyć własną aplikację uruchamianą zamiast systemu, jednak należy zdawać sobie sprawę, że napisanie takiego programu nie jest zadaniem trywialnym. Żaden z mechanizmów, którymi Windows rozpieszcza programistę nie jest dostępny, ponieważ system jeszcze nie wystartował. Nie ma dostępu do plików, nie ma rejestru, nie ma okienek, nie ma myszy, nie ma Win32. Przeczytanie znaku z klawiatury czy wyświetlenie tekstu na ekranie jest zadaniem, które prawdziwym programistom przypomni czasy prawdziwego programowania.
Wszystkie opisane dotąd obiekty (Boot Manager, Boot Loader, Windows Ntldr i aplikacja) są obiektami typu aplikacyjnego. Poza tym typem, w BCD Store zapisane mogą być obiekty typów device oraz inheritable.
Obiekty device opisują urządzenia, z których może zostać załadowany system, a których opis wykracza poza ramy pojedynczego BCD Element. Partycja dysku twardego jest w rozumieniu BCD bardzo prostym urządzeniem startowym, więc nie wymaga obiektu device. Przykładem urządzenia skomplikowanego (i używającego BCD device object) może być ramdisk stosowany do uruchamiania systemu przez sieć.
Obiekty inheritable, jak sama nazwa wskazuje, są kontenerami przechowującymi wspólne cechy przeznaczone do dziedziczenia przez wiele innych obiektów równocześnie. Takie podejście pozwala na wprowadzanie zmian w jednym tylko obiekcie i korzystanie z nich we wszystkich innych (zwłaszcza typu application), które chcą te cechy dziedziczyć. Znacząco ułatwia to zarządzanie bardziej złożonymi środowiskami. Niektóre parametry z obiektów inheritable mogą definiować cechy dla całego BCD Store, a nie tylko dla poszczególnych obiektów. Możliwe jest również ograniczenie działania obiektów BCD inheritable tylko do obiektów typu application. Przykładem obiektu inheritable jest systemowa mapa uszkodzonej pamięci. Windows Vista potrafi pamięć taką omijać, więc warto o niej powiadomić wszystkie boot loadery. Robienie tego indywidualnie dla każdego wpisu byłoby nieefektywne a w nowych wpisach opcje te mogłyby zostać przeoczone. Dlatego lepiej ustawić jeden obiekt typu {badmemory} i liczyć na to, że wszystkie inne obiekty z informacji tej skorzystają.
Każdy obiekt posiada własny, unikalny identyfikator GUID o długości 128 bitów oraz 32 bity opisu. Na ich podstawie bootmgr rozróżnia wpisy oraz jest w stanie rozpoznać typ obiektu. Co ważne, aby uniknąć wpisywania identyfikatorów typu „{7ba5d432-27b0-11dc-a569-a9f098366b64}”, narzędzia zarządzające BCD pozwalają na stosowanie aliasów „{current}” i „{default}” odpowiednio dla obiektu obecnie załadowanego i dla obiektu domyślnego.
Każdy obiekt BCD, niezależnie od typu, opisany jest przez serię BCD elements. Niektóre elementy stosowane mogą być wyłącznie do opisywania aplikacji, inne do opisywania urządzeń, a jeszcze inne są uniwersalne i mogą zostać dołączone do dowolnego obiektu BCD. Element BCD musi mieć określony typ. Typem może być łańcuch znaków, liczba, wartość logiczna lub obiekt. Podobnie jak dla BCD objects, każdy element ma swój unikalny identyfikator GUID, jednak najczęściej używane elementy BCD mają swoje aliasy pozwalające na użycie krótkiego opisu zamiast ciągu znaków i cyfr. Przykładowo, prościej napisać {globalsettings} niż {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}.
Samodzielna edycja BCD
Po tym przydługim wstępie teoretycznym przejść można do konkretów, czyli do samodzielnego edytowania BCD. Wśród mechanizmów, które to umożliwiają, wymienić należy:
| • | WMI i konsola wmic.exe. Mechanizm ten przeznaczony jest przede wszystkim dla programistów. |
| • | Systemowa aplikacja bcdedit.exe. Aplikacja ta daje pełną władzę nad BCD w formie odrobinę bardziej czytelnej niż wmic. |
| • | Interfejs udostępniany przez rejestr systemowy. Wydaje się, że działa, jednak Microsoft zdecydowanie odradza jego użycie, ponieważ nie ma gwarancji, że w nowszych wersjach systemu będzie działał poprawnie. Jeżeli ktoś chce obejrzeć, jak to wygląda w praktyce, może spojrzeć w rejestrze do gałęzi HKLM\ BCD00000000. Wyraźnie zobaczyć można serię obiektów, z których każdy opisany jest właściwymi dla niego elementami. |
| • | Narzędzie msconfig. Pozwala użytkownikowi skorzystać z GUI, ale tak naprawdę nie daje pełnej kontroli nad tym, co w BCD się dzieje. Polecane wyłącznie dla tych, dla których bcdedit jest zbyt trudny. |
Dla potrzeb świadomego użytkownika najlepsze wydaje się narzędzie bcdedit.exe Aplikacja ta obsługiwana jest z linii poleceń i aby uzyskać informację o jej obsłudze, należy wpisać bcdedit /?. Jak wspomniano we wcześniejszej części artykułu, operacje na BCD wymagają praw administratora, czyli podniesionego poziomu praw w cmd.exe.
Wpisanie bcdedit /? wyświetla listę dostępnych poleceń wraz z ich krótkim opisem. Aby otrzymać bardziej szczegółowy opis, na przykład dla polecenia export, należy wpisać „bcdedit.exe /? export”.
Możliwości programu bcdedit.exe podzielić można na trzy logiczne grupy: pracujące na całym BCD Store, pracujące na obiektach BCD oraz pracujące na elementach BCD. Wśród poleceń pracujących na BCD Store wymienić należy przede wszystkim export oraz import. Pozwalają one na zapisanie BCD do pliku, który może być wykorzystany jako kopia zapasowa lub posłużyć do sklonowania wzorcowych ustawień na innych komputerach. Zapisany plik ma format binarny, typowy dla eksportowanych gałęzi rejestru.
Najważniejsze polecenia pracujące na obiektach to:
| • | Enum – polecenie wyświetla listę zdefiniowanych obiektów. Domyślnie, dla wyświetlania używany jest kwantyfikator ACTIVE, jednak można pobrać obiekty należące do grup BOOTMGR, BOOTAPP, OSLOADER, INHERIT czy paru innych. Wyświetlenie wszystkich obiektów możliwe jest przy użyciu kwantyfikatora ALL. Polecenie wyświetlające wszystkie obiekty z BCD będzie miało postać: „bcdedit.exe /enum ALL”. |
| • | Copy – polecenie kopiuje wskazany obiekt, nadaje mu automatycznie nowy GUID i opis podany przez użytkownika w linii poleceń. Polecenie to jest dość wygodne do eksperymentowania ponieważ pozwala na przeprowadzenie testów, czy zmiany środowiska startowego bez naruszania oryginalnego obiektu w BCD. Przykładowa linia kopiująca domyślny wpis może brzmieć: bcdedit.exe /copy {default} /d ”wpis testowy”. |
| • | Delete – polecenie usuwa wskazany obiekt. Należy pamiętać, że usunięcie ostatniego wpisu typu Windows Boot Loader uniemożliwia start systemu. Na szczęście uruchomiony z płyty instalacyjnej proces recovery robi kopię istniejącego BCD, przywraca wpis i po restarcie system ożywa. |
| • | Create – polecenie tworzy nowy wpis o zadanych parametrach. |
Warto zwrócić uwagę, że polecenia bcdedit wyświetlając GUID obiektu posługują się aliasami a nie pełnymi identyfikatorami. Zyskuje na tym czytelność, ale jeżeli komuś zależy na prawdziwych identyfikatorach, może użyć opcji /V.
W praktyce, częściej od zarządzania obiektami BCD spotyka się zarządzanie elementami dla już istniejących obiektów. Służą do tego tylko dwa polecenia: set i deletevalue. Jedno tworzy lub ustawia wartości elementu a drugie – usuwa cały element. O elementach zostanie napisane jeszcze parę słów w dalszej części artykułu.
Ostatnią grupą poleceń dostępnych w bcdedit są polecenia związane z zarządzaniem obiektem typu Boot Manager. Jak już wspomniano, obiekt ten odpowiada między innymi za kolejność wyświetlania dostępnych systemów, czas na wybór systemu oraz system domyślny, uruchamiany, jeżeli przez zadany czas użytkownik nic nie wybierze. Parametry Boot Manager Object ustawia się przez polecenia:
| • | Displayorder – ustawia kolejność wyświetlania przez bootmgr obiektów typu Windows Boot Loader. Umożliwia to ułożenie dostępnych systemów w najwygodniejszej kolejności. Istnieją opcje pozwalające na ustawienie dostępnych obiektów w zadanej kolejności, na usunięcie obiektu z listy oraz na dodanie dowolnego obiektu na początku lub na końcu listy. To w praktyce wystarcza do dowolnego poukładania pozycji. |
| • | Bootsequence – robi dokładnie to samo, co display order, jednak ustalona kolejność obowiązuje tylko przy najbliższym restarcie komputera. Później jest usuwana i przywracana jest kolejność obowiązująca wcześniej. |
| • | Default – pozwala na ustawienie, który BCD Object jest wybierany jeżeli upłynie czas przeznaczony na decyzję. |
| • | Timeout – pozwala na ustawienie czasu na decyzję. |
| • | Toolsdisplayorder – pozwala na zarządzanie kolejnością obiektów typu aplikacja. |
Wartym wzmianki poleceniem jest jeszcze bcdedit /? ID. Polecenie to wyświetla wszystkie aliasy, czyli dozwolone do użycia skrócone nazwy identyfikatorów. Istnieją również opcje związane z EMS (Emergency Management Service) oraz debugowaniem systemu.
Wspomniane wcześniej polecenia set i deletevalue tak naprawdę służą do zarządzania parametrami systemów uruchamianych przez BCD. O ile operacja dodania nowego systemu czy własnej aplikacji jest stosunkowo rzadka, o tyle zmiana parametrów już istniejącego systemu może się przydać. Choć dla różnych typów obiektów (boot manager, aplikacje, Windows Ntldr, Windows Boot Loader) istnieją różne rodzaje elementów, to jednak najciekawsze i najbardziej użyteczne wydają się te związane z systemem operacyjnym, czyli z Windows Boot Loader. Wśród elementów, wymienić należy:
| • | BOOTLOG – włącza rejestrowanie dziennika startu systemu. |
| • | BOOTSTATUSPOLICY – ustawia zachowanie systemu w przypadku napotkania błędu podczas uruchamiania |
| • | LASTKNOWNGOOD – wymusza załadowanie ostatniej znanej konfiguracji |
| • | NOCRASHAUTOREBOOT – wyłącza automatyczny restart po błędzie krytycznym |
| • | QUIETBOOT – wyłącza tryb graficzny podczas startu systemu |
| • | SAFEBOOT – włącza ograniczony zestaw sterowników czyli tryb awaryjny |
| • | SOS – wyświetla informacje o ładowanych sterownikach |
| • | WINPE – uruchamia Windows PE |
| • | PAE – włącza Physical Address Extensions |
| • | HALBREAKPOINT – uruchamia specjalny break point z bibliotek HAL. Z punktu widzenia zwykłego użytkownika powoduje to malowniczy blue screen w czasie uruchamiania systemu. Naprawienie tak zepsutego systemu nie jest możliwe przez startup rep air z płyty instalacyjnej i jeżeli wszystkie obiekty w BCD go mają – najlepiej uruchomić Windows PE i stamtąd użyć bcdedit.exe ustawiając halbreakpoint na false lub po prostu usuwając ten element. |
Pełna lista parametrów dostępnych dla obiektów Windows Boot Loader dostępna jest po wpisaniu polecenia bcdedit.exe /? types osloader.
Samodzielne uruchomienie bcdedit.exe - praktyczne wskazówki
Na koniec kilka dobrych, praktycznych rad dla tych, którzy nie chcą się ograniczyć do teoretycznych rozważań o BCD i postanowili samodzielnie uruchomić bcdedit.exe.
| • | Przed eksperymentami warto zrobić export BCD. Może być nawet do pliku na tym samym dysku, na którym leży BCD. Jak to zwykle bywa z kopią zapasową, lepiej żeby nie był potrzebna, ale dobrze ją mieć. |
| • | System, który nie startuje, najlepiej naprawić z command Line Windows PE dostępnego z programu instalacyjnego Windows Vista (po uruchomieniu komputera z płyty DVD). Można wtedy wykonać import plików i naprawić popsuty BCD standardowym poleceniem bcdedit. W popsutym środowisku startowym Windows PE może uruchamiać się nawet kilkanaście minut, ale w końcu zadziała. |
| • | Dopóki operacje dotyczą konkretnego obiektu Windows Boot Loader, najbezpieczniej wykonać kopię działającego obiektu i właśnie kopię następnie modyfikować. W razie pomyłki, zawsze można wybrać z menu startowego bootmgr działającą wersję. Jeżeli testy się powiodą, można nową wersję obiektu ustawić jako domyślną, a nawet skasować oryginalny obiekt. |
Podsumowanie
Pozostaje życzyć dobrej zabawy i udanych restartów. Warto jednak zwrócić uwagę, że w artykule prześledzono jedynie najpospolitszy przypadek. Celowo nie napisano o tworzeniu i uruchamianiu aplikacji uruchamianych przez bootmgr.
Całkowicie pominięto niestandardowe BCD system store, start z urządzeń innych niż dysk twardy, czy wznawianie systemu po hibernacji. Nie wgłębiano się w zagadnienia związane z Windows PE i uruchamianiem programu instalacyjnego. Praktycznie tylko hasłowo wspomniany został mechanizm BitLocker, pominięto EFI oraz UEFI. Nie ma ani słowa o debugowaniu ani o alternatywnych bibliotekach HAL. Są to niezwykle ciekawe zagadnienia, każde warte oddzielnego artykułu, jednak na tyle rozbudowane, że ich wkomponowane w niniejszy, bardzo skrócony opis sprawiłoby, że stałby się on niemal całkowicie nieczytelny.
Należy jednak pamiętać, że interesując się poważnie startem systemu Windows Vista ich również nie wolno pominąć.
 | Grzegorz Tworek (Konsultant ISCG, MVP) |