Windows-Verwaltung

Einblick in den Windows Vista-Kernel: Teil 2

Mark Russinovich

Kurz zusammengefasst:

• Speicherverwaltung
• Starten und Herunterfahren
• Energieverwaltung

Letzten Monat wurden im ersten Teil dieser dreiteiligen Reihe die Verbesserungen am Windows Vista-Kernel im Bereich von Prozessen und E/A-Vorgängen besprochen.

In diesem Beitrag geht es um die fortgeschrittene Speicherverwaltung in Windows Vista und die wichtigsten Verbesserungen bezüglich Systemstart, Herunterfahren und Energieverwaltung (Teil 1).

Jede neue Version von Windows® verbessert die Skalierbarkeit und Leistung. Dies trifft auch auf Windows Vista™ zu. Der Speicher-Manager von Windows Vista umfasst zahlreiche Verbesserungen. Dazu gehören die umfangreichere Verwendung von Synchronisierungsmethoden ganz ohne Sperren, differenziertere Sperren, engeres Verpacken von Datenstrukturen, größere E/A-Auslagerungsdateien, Unterstützung moderner GPU-Speicherstrukturen und eine effizientere Verwendung des Übersetzungsnachschlagepuffers (Translation Lookaside Buffer, TLB). Darüber hinaus bietet die Windows Vista-Speicherverwaltung jetzt eine dynamische Speicherplatzzuweisung für Adressen im Hinblick auf die Anforderungen verschiedener Arbeitsauslastungen.

Vier leistungssteigernde Features, in denen neue Technologien eingesetzt werden, befinden sich zum ersten Mal auf dem Prüfstand eines Betriebssystems. Es geht um die folgenden Funktionen in Windows Vista: SuperFetch, ReadyBoost, ReadyBoot und ReadyDrive. Diese Features werden weiter unten ausführlich besprochen.

Dynamischer Kerneladressbereich

Windows und die Anwendungen, die unter Windows ausgeführt werden, hatten Probleme mit der Beschränkung des Adressbereichs von 32-Bit-Prozessoren. Der Windows-Kernel ist standardmäßig auf 2 GB bzw. die Hälfte des gesamten virtuellen 32-Bit-Adressbereichs begrenzt, wobei die andere Hälfte für die Verwendung durch den Prozessor vorgesehen ist, dessen Thread aktuell auf der CPU ausgeführt wird. Innerhalb seiner Hälfte muss der Kernel Folgendes zuordnen: sich selbst, die Gerätetreiber, den Dateisystemcache, die Kernelstapel, die sitzungsspezifischen Codedatenstrukturen und sowohl die nicht ausgelagerten (im physischen Speicher eingeschlossenen) als auch die ausgelagerten, von Gerätetreibern zugeordneten Puffer. Vor Windows Vista wurde durch den Speicher-Manager zur Startzeit festgelegt, wie viel Adressbereich diesen verschiedenen Zwecken zuzuweisen ist, doch diese Inflexibilität führte manchmal dazu, dass einer der Bereiche vollständig ausgelastet war, während andere noch jede Menge verfügbaren Speicherplatz hatten. Die Auslastung eines Bereichs kann dazu führen, dass Anwendungen fehlschlagen und Gerätetreiber davon abgehalten werden, E/A-Vorgänge abzuschließen.

Im 32-Bit-Windows Vista verwaltet der Speicher-Manager den Adressbereich des Kernels dynamisch und sorgt für die Zuordnung bzw. Freigabe von Bereichen für verschiedene Zwecke, je nachdem, was die Arbeitsauslastung erfordert. Folglich kann der virtuelle Arbeitspeicher, der verwendet wird, um ausgelagerte Puffer zu speichern, zunehmen, wenn Gerätetreiber mehr fordern, und er kann schrumpfen, wenn die Treiber ihn freigeben. Windows Vista ist deshalb in der Lage, eine größere Auswahl von Arbeitsauslastungen zu verarbeiten. Dies gilt gleichermaßen für „Longhorn“, die zukünftige 32-Bit-Version von Windows Server®, die so skaliert wird, dass sie eine größere Anzahl von gleichzeitigen Terminalserverbenutzern ermöglicht.

Selbstverständlich stellen Einschränkungen des Adressbereichs auf 64-Bit-Windows Vista-Systemen derzeit keine wirklich Problem dar und erfordern daher keine besondere Behandlung, da sie bis zu ihren jeweiligen Höchstgrenzen konfiguriert sind.

Speicherprioritäten

Genauso wie Windows Vista E/A-Prioritäten hinzufügt (siehe Teil 1), fügt es auch Speicherprioritäten hinzu. Um zu verstehen, wie Speicherprioritäten von Windows verwendet werden, sollte verstanden werden, wie der Speicher-Manager seinen Speichercache, der die Standbyliste genannt wird, implementiert. In allen Versionen von Windows vor Windows Vista wurde eine physische Seite (in der Regel 4 KB), die einem Prozess gehört und vom System freigegeben wurde, vom Speicher-Manager in der Regel an das Ende der Standbyliste gestellt. Wenn der Prozess erneut auf die Seite zugreifen wollte, nahm der Speicher-Manager die Seite aus der Standbyliste und wies sie wieder dem Prozess zu. Wenn ein Prozess eine neue Seite des physischen Speichers verwenden wollte und kein freier Speicherplatz verfügbar war, gab der Speicher-Manager ihm die Seite am Anfang der Standbyliste. Dieses Schema hat alle Seiten in der Standbyliste praktisch gleich behandelt und ist dabei bei der Sortierung nur nach dem Zeitpunkt ihrer Platzierung in der Liste vorgegangen.

In Windows Vista hat jede Seite des Speichers eine Priorität im Bereich von 0 bis 7, und deshalb unterteilt der Speicher-Manager die Standbyliste in acht Listen, von denen jede eine bestimmte Priorität speichert. Wenn der Speicher-Manager eine Seite aus der Standbyliste herausnehmen will, nimmt er die Seiten zuerst aus den Listen mit einer niedrigen Priorität. Die Priorität einer Seite reflektiert normalerweise die Priorität des Threads, der die Zuordnung als Erster auslöst. (Wenn die Seite freigegeben ist, reflektiert sie die höchsten Speicherprioritäten der freigegebenen Threads.) Ein Thread erbt seinen Seitenprioritätswert von dem Prozess, zu dem der gehört. Der Speicher-Manager verwendet niedrige Prioritäten für Seiten, die er vom Datenträger in spekulativer Weise liest, wenn er die Speicherzugriffe eines Prozesses erwartet.

Standardmäßig haben Prozesse einen Seitenprioritätswert von 5, doch Funktionen ermöglichen den Anwendungen und dem System, die Prozess- und Threadseitenprioritätswerte zu ändern. Die wirkliche Stärke der Speicherprioritäten kommt nur dann zur Geltung, wenn die relativen Prioritäten der Seiten auf einer Makroebene verstanden werden, was die Aufgabe von SuperFetch ist.

SuperFetch

Eine wichtige Änderung, die am Speicher-Manager vorgenommen wurde, betrifft die Art, wie er den physischen Speicher verwaltet. Die Standbylistenverwaltung, die von früheren Versionen von Windows verwendet wurden, haben zwei Einschränkungen. Zum einen verlässt sich die Priorisierung der Seiten nur auf das kürzlich gezeigte Verhalten von Prozessen und sieht ihre zukünftigen Speicheranforderungen nicht voraus. Zum anderen sind die zur Priorisierung verwendeten Daten auf die Liste der Seiten begrenzt, die zu einem beliebigen Zeitpunkt einem Prozess gehören. Diese Mängel können zu Szenarios wie dem „Mittagspausensyndrom“ führen. Sie überlassen Ihren Computer eine kurze Zeit sich selbst, und es wird eine speicherintensive Systemanwendung (z. B. ein Antivirenscan oder eine Datenträgerdefragmentierung) ausgeführt. Diese Anwendung erzwingt, dass der Code und die Daten, die Ihre aktiven Anwendungen im Cache zwischengespeichert hatten, durch die speicherintensiven Aktivitäten überschrieben werden. Wenn Sie sich wieder an den Computer setzen, finden Sie eine verlangsamte Leistung vor, da die Anwendungen ihre Daten und den Code vom Datenträger abrufen müssen.

In Windows XP wurde die Vorabrufunterstützung eingeführt, der die Leistung beim System- und Anwendungsstart verbesserte. Diese Verbesserung wurde dadurch erreicht, dass große Datenträger-E/A-Vorgänge durchgeführt wurden, um die Code- und Dateisystemdaten vorab zu laden, die aufgrund von vorherigen System- und Anwendungsstarts vorhergesehen wurden. Windows Vista geht mit SuperFetch, einem Speicherverwaltungsschema, das die Methode des am längsten zurückliegenden Zugriffs um Verlaufsinformationen und eine proaktive Speicherverwaltung erweitert, einen großen Schritt weiter.

SuperFetch ist in %SystemRoot%\System32\Sysmain.dll als ein Windows-Dienst implementiert, der innerhalb eines Diensthostprozesses (%SystemRoot%\System32\Svchost.exe) ausgeführt wird. Das Schema verlässt sich auf die Unterstützung des Speicher-Managers, damit es Verlaufsinformationen zur Seitenverwendung abrufen und den Speicher-Manager anweisen kann, Daten und Code von Dateien auf Datenträger oder von einer Auslagerungsdatei in die Standbyliste vorab zu laden und den Seiten Prioritäten zuzuweisen. Der SuperFetch-Dienst dehnt die Seitenverfolgung im Wesentlichen auf die Daten und den Code aus, die sich einmal im Speicher befanden, die jedoch vom Speicher-Manager wiederverwendet wurden, um für neue Daten und Code Platz zu schaffen. Er speichert diese Informationen in Szenariodateien mit einer .db-Erweiterung im %SystemRoot%\Prefetch-Verzeichnis zusammen mit Standardvorabrufdateien, die zur Optimierung des Anwendungsstarts verwendet werden. Aufgrund dieser tief reichenden Kenntnis der Speicherauslastung kann SuperFetch Daten und Code vorab laden, wenn der physische Speicher verfügbar wird.

Wann immer Speicher frei wird, z. B. wenn eine Anwendung beendet wird oder wenn sie Speicher freigibt, fordert der SuperFetch den Speicher-Manager auf, kürzlich entfernte Daten und Code abzurufen. Dies wird mit einer Geschwindigkeit von ein paar Seiten pro Sekunde von E/A-Vorgängen mit sehr niedriger Priorität ausgeführt, damit das Vorabladen sich nicht auf den Benutzer oder die anderen aktiven Anwendungen auswirkt. Wenn Sie sich daher in der Mittagspause von Ihrem Computer entfernen und eine speicherintensive Hintergrundaufgabe dazu führt, dass der Code und die Daten Ihrer aktiven Anwendungen in Ihrer Abwesenheit aus dem Speicher entfernt werden, kann SuperFetch oft alles oder einen Großteil davon wieder zurückholen, bevor Sie zu Ihrem Arbeitsplatz zurückkehren. SuperFetch umfasst außerdem eine bestimmte Unterstützung je nach Szenario für Ruhezustand, Standby, Fast User Switching (FUS) und Anwendungsstart. Wenn das System beispielsweise in den Ruhestand übergeht, werden von SuperFetch Daten und Code in der Ruhezustanddatei gespeichert, denn es geht (aufgrund der vorherigen Ruhezustände) davon aus, dass bei der nachfolgenden Wiederaufnahme auf sie zugegriffen wird. Wenn Sie im Gegensatz dazu Windows XP wieder aufnehmen, müssen zuvor zwischengespeicherte Daten wieder vom Datenträger abgelesen werden, wenn darauf verwiesen wird.

Weitere Informationen dazu, wie sich SuperFetch auf den verfügbaren Speicher auswirkt, erhalten Sie in der Randleiste „Überwachen von SuperFetch“.

Überwachen von SuperFetch

Nachdem Sie eine Zeit lang das Windows Vista-System verwendet haben, werden Sie in der Leistungsseite des Task-Managers feststellen, dass der Zähler für den freien physischen Speicher eine niedrige Zahl angibt. Das liegt daran, dass SuperFetch und die Standardzwischenspeicherung in Windows den gesamten verfügbaren physischen Speicher nutzen, um die Datenträgerdaten zwischenzuspeichern. Wenn Sie zum Beispiel das erste Mal starten und sofort den Task-Manager ausführen, werden Sie feststellen, dass der Wert für den freien Speicherplatz sinkt und die Größe des zwischengespeicherten Speichers zunimmt. Ein anderes Beispiel: Wenn Sie ein speicherintensives Programm ausführen und es dann beenden (das funktioniert mit jeder beliebigen Freeware zur Arbeitsspeicheroptimierung, die große Speichermengen zuordnet und sie dann wieder freigibt) oder wenn Sie nur eine sehr große Datei kopieren, steigt der Wert des freien Speichers und der Wert für den genutzten physischen Speicher nimmt ab, während das System den freigegebenen Speicher wieder zurückgewinnt. Langfristig gesehen wird der Cache jedoch von SuperFetch erneut mit den Daten gefüllt, die aus dem Speicher entfernt wurden, sodass der Wert für die Zwischenspeicherung steigt und der Wert des freien Speichers abnimmt.

Überwachen des Speichers(Klicken Sie zum Vergrößern auf das Bild)

ReadyBoost

Was Geschwindigkeit angeht, ziehen CPUs und Speicher derzeit zügig an Festplatten vorbei. Deshalb stellen Datenträger einen allgemeinen Systemleistungsengpass dar. Zufällige Datenträger-E/A-Vorgänge sind besonders teuer, weil die Kopfsuchzeiten von Datenträgern sich in der Regel in einem Bereich von 10 Millisekunden befinden. Das ist eine Ewigkeit für die heutigen 3 GHz-Prozessoren. Während sich der Arbeitsspeicher ideal für das Zwischenspeichern von Datenträgerdaten eignet, ist er verhältnismäßig teuer. Flashspeicher dagegen sind normalerweise billiger und können zufälliges Lesen bis zu 10 Mal schneller verarbeiten als eine typische Festplatte. Windows Vista enthält deshalb das ReadyBoost-Feature, um Flashspeichergeräte zu nutzen. Dabei wird eine unmittelbare Zwischenspeicherebene erstellt, die logisch zwischen dem Speicher und den Festplatten positioniert ist.

ReadyBoost besteht aus einem Dienst, der in %SystemRoot%\System32\Emdmgmt.dll (ausgeführt in einem Servicehostdienst) implementiert wurde, und hat einen Volumefiltertreiber, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd steht für External Memory Device. Das ist der Arbeitsname, der für ReadyBoost während seiner Entwicklung verwendet wurde.) Wenn Sie ein Flashgerät wie einen USB-Schlüssel in ein System einfügen, untersucht der ReadyBoost-Dienst das Gerät, um seine Leistungsmerkmale zu bestimmen, und speichert diese Ergebnisse in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt (siehe Abbildung 1).

Abbildung 1** Testergebnisse von ReadyBoost in der Registrierung **(Klicken Sie zum Vergrößern auf das Bild)

Falls Sie nicht bereits ein Gerät für die Zwischenspeicherung verwenden und falls das neue Gerät zwischen 256 MB und 32 GB groß ist, eine Übertragungsrate von 2,5 MB/s oder höher für zufällige 4 KB-Lesevorgänge und eine Übertragungsrate von 1,75 MB/s oder höher für zufällige 512 KB-Schreibvorgänge aufweist, dann werden Sie von ReadyBoost gefragt, ob Sie bis zu 4 GB des Speichers der Datenträgerzwischenspeicherung zuweisen möchten. (Obwohl ReadyBoost NTFS verwenden kann, beschränkt es die maximale Cachegröße auf 4 GB, um FAT32-Einschränkungen zu berücksichtigen.) Wenn Sie zustimmen, erstellt der Dienst im Stammverzeichnis des Geräts eine Cachedatei mit dem Namen ReadyBoost.sfcache und weist SuperFetch an, den Cache im Hintergrund wieder zu füllen.

Nachdem der ReadyBoost-Dienst das Zwischenspeichern initialisiert, fängt der Ecache.sys-Gerätetreiber alle Lese- und Schreibvorgänge ab, speichert sie auf lokalen Festplattenvolumes (beispielsweise C:\) und kopiert alle Daten, die geschrieben werden, in die Cachedatei, die der Dienst erstellt hat. Ecache.sys komprimiert die Daten und erreicht in der Regel ein Komprimierungsverhältnis von 2:1, sodass eine 4 GB Cachedatei gewöhnlich 8 GB Daten enthält. Der Treiber verschlüsselt jeden Block, den er mit der AES-Verschlüsselung (Advanced Encryption Standard) schreibt, mit einem zufällig generierten startspezifischen Sitzungsschlüssel, um den Datenschutz der Daten im Cache des Geräts zu garantieren, falls das Gerät aus dem System entfernt wird.

Wenn ReadyBoost zufällige Lesevorgänge erkennt, die aus dem Cache bedient werden können, werden sie aus dem Cache verarbeitet. Da Festplatten jedoch einen besseren sequenziellen Lesezugriff haben als Flashspeicher, ermöglicht es den Lesevorgängen, die Teil eines sequenziellen Zugriffsmusters sind, den direkten Zugriff auf den Datenträger, auch wenn sich die Daten im Cache befinden.

ReadyBoot

Windows Vista verwendet den gleichen Vorabrufvorgang, den Windows XP immer dann verwendet, wenn das System weniger als 512 MB Speicher zur Verfügung hat. Wenn das System jedoch 700 MB oder mehr Arbeitsspeicher hat, verwendet es einen RAM-Cache, um den Startvorgang zu optimieren. Die Größe des Cache hängt vom verfügbaren Gesamtarbeitsspeicher ab, ist jedoch groß genug, um einen geeigneten Cache zu erstellen und dem System trotzdem den Speicher zu gewähren, den es für einen reibungslosen Start benötigt.

Nach jedem Systemstart verwendet der ReadyBoost-Dienst (der gleiche Dienst, der das oben beschriebene ReadyBoost-Feature implementiert) eine CPU-Leerlaufzeit, um für den nächsten Systemstart einen Cacheplan für die Systemstartzeit zu erstellen. Er analysiert die Dateiablaufverfolgungsinformationen der fünf vorherigen Systemstarts und stellt fest, auf welche Dateien zugegriffen wurde und wo sie sich auf dem Datenträger befinden. Er speichert die verarbeiteten Informationen in %SystemRoot%\Prefetch\Readyboot als .fx-Dateien und speichert den Cacheplan unter HKLM\System\CurrentControlSet\Services\Ecache\Parameters in den REG_BINARY-Werten, die nach den internen Datenträgervolumes, auf die sie sich beziehen, benannt werden.

Der Cache wird vom gleichen Gerätetreiber implementiert, der den ReadyBoost-Cache (Ecache. sys) implementiert, doch das Laden des Zwischenspeichers wird beim Systemstart vom ReadyBoost-Dienst geleitet. Obwohl der Cache des Systemstarts so komprimiert wird wie der ReadyBoost-Cache, besteht ein weiterer Unterschied zwischen der ReadyBoost- und der ReadyBoot-Cacheverwaltung. Im ReadyBoot-Modus ändert sich, abgesehen von Aktualisierungen des ReadyBoot-Diensts, der Cache nicht, um die Daten, die während des Systemstarts gelesen oder geschrieben werden, zu reflektieren. Der ReadyBoost-Dienst löscht den Cache 90 Sekunden nach dem Systemstart, oder wenn andere Speicheranforderungen es rechtfertigen, und zeichnet die Cachestatistiken in HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats auf (siehe Abbildung 2). Microsoft-Leistungstests zeigen, dass ReadyBoot eine Verbesserung der Leistung ermöglicht, die ungefähr 20 Prozent über der Leistung des älteren Windows XP-Vorabrufs liegt.

Abbildung 2** ReadyBoot-Leistungsstatistiken **(Klicken Sie zum Vergrößern auf das Bild)

ReadyDrive

ReadyDrive ist ein Windows Vista-Feature, das die neuen Hybridfestplatten (H-HDD) nutzt. Eine H-HDD ist ein Datenträger mit eingebettetem permanentem Flashspeicher (auch NVRAM genannt). Reguläre H-HDDs verfügen über 50 MB bis 512 MB Cache, doch die Cachebeschränkung in Windows Vista liegt bei 2 TB.

Windows Vista verwendet ATA-8-Befehle, um die Datenträgerdaten zu definieren, die im Flashspeicher gespeichert werden sollen. Zum Beispiel werden in Windows Vista Systemstartdaten beim Herunterfahren des Systems im Cache gespeichert, was einen schnelleren Neustart ermöglicht. Außerdem werden im Ruhezustand des Systems Teile der Ruhezustanddateidaten im Cache gespeichert, damit die nachfolgende Wiederaufnahme schneller erfolgt. Da der Cache sogar dann aktiviert wird, wenn der Datenträger heruntergefahren ist, kann Windows den Flashspeicher als einen Cache zum Schreiben auf den Datenträger verwenden, was verhindert, dass der Datenträger hochgefahren wird, wenn das System vom Akku betrieben wird. Wird der Datenträgerspindel ausgeschaltet, kann dies viel Strom sparen, der bei normaler Nutzung vom Datenträgerlaufwerk verbraucht wird.

Startkonfigurationsdatenbank

Windows Vista hat mehrere Aspekte des Systemstarts und Herunterfahrens verbessert. Der Systemstart wurde folgendermaßen verbessert: Es wurde eine Startkonfigurationsdatenbank (Boot Configuration Database, BCD) für das Speichern der System- und Betriebssystem-Startkonfiguration, ein neuer Ablauf und eine neue Organisation für Systemstartprozesse, eine neue Anmeldearchitektur und die Unterstützung für verzögerte Autostartdienste eingeführt. Die Änderungen für das Herunterfahren in Windows Vista umfassen die Benachrichtigung für Windows-Dienste vor dem Herunterfahren, die Reihenfolge von Windows-Diensten beim Herunterfahren und eine wichtige Änderung an der Art, wie das Betriebssystem die Übergänge der Energieverwaltung handhabt.

Eine der offensichtlichsten Änderungen am Startprozess ist das Fehlen von Boot.ini im Stammverzeichnis des Systemvolumes. Das liegt daran, dass die Startkonfiguration, die auf früheren Versionen von Windows in der Boot.ini-Textdatei gespeichert wurde, jetzt in der Startkonfigurationsdatenbank gespeichert wird. Einer der Gründe dafür, warum Windows Vista die Startkonfigurationsdatenbank verwendet, liegt darin, dass sie die zwei aktuellen Startkonfigurationen vereinigt, die von Windows unterstützt werden: MBR (Master Boot Record) und EFI (Extensible Firmware Interface). MBR wird gewöhnlich von x86- und x64-Desktopsystemen verwendet, während EFI von Itanium-basierten Systemen verwendet wird (obwohl anzunehmen ist, dass Desktop-PCs schon bald mit EFI-Unterstützung geliefert werden). Die Startkonfigurationsdatenbank abstrahiert die Firmware und hat andere Vorteile gegenüber Boot.ini, wie z. B. Unterstützung für Unicode-Zeichenfolgen und alternative, vor dem Systemstart ausführbare Dateien.

Die Startkonfigurationsdatenbank wird im Grunde auf der Festplatte gespeichert, und zwar in einer Registrierungsgruppe, die in die Windows-Registrierung für den Zugriff über die Registrierungs-APIs geladen wird. Auf PCs speichert Windows sie in \Boot\Bcd auf dem Systemvolume. Auf EFI-Systemen wird sie auf der EFI-Systempartition gespeichert. Wenn die Registrierungsgruppe geladen ist, erscheint sie unter HKLM\Bcd00000000, doch ihr internes Format ist nicht dokumentiert, sodass die Bearbeitung die Verwendung eines Tools wie %SystemRoot%\System32\Bcdedit.exe erfordert. Schnittstellen für das Manipulieren der Startkonfigurationsdatenbank werden außerdem den Skripts und benutzerdefinierten Editoren über WMI (Windows Management Instrumentation) zur Verfügung gestellt. Sie können das Dienstprogramm für die Windows-Systemkonfiguration (%SystemRoot%\System32\Msconfig.exe) verwenden, um grundlegende Parameter zu bearbeiten oder hinzuzufügen, z. B. die Optionen für das Kerneldebuggen.

Die Startkonfigurationsdatenbank trennt plattformübergreifende Starteinstellungen, wie z. B. die Standard-Betriebssystemauswahl und die Startmenüzeitsperre, von betriebssystemspezifischen Einstellungen, wie z. B. den Betriebssystem-Startoptionen und dem Pfad zum Betriebssystem-Ladeprogramm. In Abbildung 3 wird zum Beispiel illustriert, dass beim Ausführen von Bcdedit ohne Verwendung von Befehlszeilenoptionen die Plattformeinstellungen im Abschnitt „Windows-Start-Manager“ oben auf der Ausgabe angezeigt werden, gefolgt von betriebssystemspezifischen Einstellungen im Abschnitt „Windows-Startladeprogramm“.

Abbildung 3** In BCDEdit angezeigte Einstellungen **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Sie eine Windows Vista-Installation starten, teilt dieses neue Schema die Aufgaben, die auf älteren Versionen von Windows vom Betriebssystemladeprogramm (Ntldr) verarbeitet wurden, in zwei verschiedene EXE-Dateien: \BootMgr und %SystemRoot%\System32\Winload.exe. Bootmgr liest die Startkonfigurationsdatenbank und zeigt das Startmenü des Betriebssystems an, während Winload.exe das Betriebssystem lädt. Wenn Sie einen ordnungsgemäßen Start durchführen, lädt Winload.exe die Systemstartgerätetreiber und zentralen Betriebssystemdateien, einschließlich Ntoskrnl.exe, und überträgt die Steuerung auf das Betriebssystem. Wenn das System aus dem Ruhezustand wiederhergestellt wird, führt es %SystemRoot%\System32\Winresume.exe aus, um die Ruhezustanddaten in den Speicher zu laden und das Betriebssystem wiederherzustellen.

Bootmgr unterstützt außerdem zusätzliche, vor dem Start ausführbare Dateien. Windows Vista enthält die Windows-Speicherdiagnose (\Boot\Memtest.exe), die als eine Option zum Überprüfen des RAM-Zustands vorkonfiguriert ist, doch Drittanbieter können ihre eigenen vor dem Start ausführbare Dateien hinzufügen, die als Optionen im Startmenü von Bootmgr angezeigt werden.

Startprozesse

In älteren Versionen von Windows war die Beziehung zwischen verschiedenen Systemprozessen nicht intuitiv. Bei Systemstart zum Beispiel werden vom interaktiven Anmelde-Manager (%SystemRoot%\System32\Winlogon.exe) der Dienst für das lokale Sicherheitsautoritäts-Subsystem (Lsass.exe) und der Dienststeuerungs-Manager (Services.exe) gestartet. Des Weiteren verwendet Windows einen Namespacecontainer, der Sitzung genannt wird, um die Prozesse zu isolieren, die in verschiedenen Anmeldesitzungen ausgeführt werden. Vor Windows Vista mussten sich die Benutzer an der gemeinsam mit der Konsole verwendeten Sitzung 0 anmelden. Das ist die von Systemprozessen verwendete Sitzung, die potenzielle Sicherheitsrisiken verursachte. Solch ein Problem trat zum Beispiel dann auf, wenn ein schlecht geschriebener Windows-Dienst, der in Sitzung 0 ausgeführt wurde, eine Benutzeroberfläche auf der interaktiven Konsole anzeigte und dadurch schädlichen Programmen ermöglichte, das Fenster durch Methoden wie den so genannten Shatter Attacks anzugreifen und sich möglicherweise Administratorrechte zu verschaffen.

Um diese Probleme zu behandeln, wurden mehrere Systemprozesse für Windows Vista neu entworfen. Der Sitzungs-Manager (Smss.exe) ist der erste Benutzermodusprozess, der wie in älteren Versionen von Windows beim Systemstart erstellt wird, doch in Windows Vista wird eine zweite Instanz des Sitzungs-Managers gestartet, um Sitzung 0 zu konfigurieren, die ausschließlich den Systemprozessen zugeordnet ist. Der Sitzungs-Manager-Prozess für Sitzung 0 startet die Windows-Startanwendung (Wininit.exe), ein Windows-Subsystemprozess (Csrss.exe) für Sitzung 0, und wird dann beendet. Die Windows-Startanwendung fährt fort, indem sie den Dienststeuerungs-Manager, den Dienst für das lokale Sicherheitsautoritäts-Subsystem und einen neuen Prozess, den lokalen Sitzungs-Manager (Lsm.exe), der die Terminalserververbindungen für den Computer verwaltet, startet.

Wenn ein Benutzer sich beim System anmeldet, erstellt der anfängliche Sitzungs-Manager eine neue Instanz von sich, um die neue Sitzung zu konfigurieren. Der neue Smss.exe-Prozess startet einen Windows-Subsystemprozess und einen Winlogon-Prozess für die neue Sitzung. Der Umstand, dass der Sitzungs-Manager sich selbst kopiert, um neue Sitzungen zu initialisieren, bietet keine Vorteile auf einem Clientsystem, doch auf Windows Server „Longhorn“-Systemen, die als Terminalserver fungieren, können mehrere Kopien gleichzeitig ausgeführt werden, um eine schnellere Anmeldung mehrerer Benutzer zu ermöglichen.

Mit dieser neuen Architektur werden Systemprozesse, einschließlich Windows-Diensten, in Sitzung 0 isoliert. Wenn ein Windows-Dienst, der in Sitzung 0 ausgeführt wird, eine Benutzeroberfläche anzeigt, benachrichtigt der Dienst zur Erkennung interaktiver Dienste (%SystemRoot%\System32\UI0Detect.exe) alle angemeldeten Administratoren, indem er im Sicherheitskontext des Benutzers eine neue Kopie von sich selbst startet und die in Abbildung 4 dargestellte Nachricht anzeigt. Wenn der Benutzer die Schaltfläche „Show me the message“ (Meldung anzeigen) auswählt, schaltet der Dienst auf den Windows-Dienstdesktop, auf dem der Benutzer mit der Benutzeroberfläche des Diensts interagieren und dann zu seinem/ihrem eigenen Desktop zurückkehren kann. Weitere Informationen zu den Prozessen beim Systemstart erhalten Sie in der Randleiste „Anzeigen der Startprozessbeziehungen“.

Abbildung 4** Anzeige eines Fensters durch den Dienst **(Klicken Sie zum Vergrößern auf das Bild)

Anzeigen der Startprozessbeziehungen

Sie können den Process Explorer von Sysinternals (microsoft.com/technet/sysinternals) verwenden, um die Prozessstartstruktur von Windows Vista anzuzeigen.

Der Screenshot enthält die Sitzungsspalte, die Sie durch den Spaltendialog von Process Explorer hinzufügen können. Der hervorgehobene Prozess ist der anfängliche Smss.exe-Prozess. Darunter befinden sich Csrss.exe und Wininit.exe der Sitzung 0, die linksbündig ausgerichtet sind, weil ihr übergeordneter Prozess, die Instanz von Smss.exe, die die Sitzung 0 konfiguriert hat, beendet wurde. Die drei untergeordneten Elemente von Wininit sind Services.exe, Lsass.exe und Lsm.exe.

Prozess Explorer ermittelt, dass ein Satz von Prozessen in Sitzung 1 ausgeführt wird, und das ist die Sitzung, bei der ich durch eine Remotedesktopverbindung angemeldet bin. Process Explorer zeigt die Prozesse, die im selben Konto wie er selbst ausgeführt werden, blau markiert an. Abschließend wurde Sitzung 2 initialisiert, um die Vorkehrungen für einen Benutzer zu treffen, der sich bei der Konsole anmeldet und eine neue Anmeldesitzung erstellt. Es ist diese Sitzung, in der Winlogon LogonUI ausführt, um dem Benutzer einer neuen Konsole die Aufforderung zu erteilen, STRG+ALT+ENTF zu drücken, um sich anzumelden. Es ist ebenfalls diese Sitzung, in der Logonui.exe den Benutzer zur Angabe seiner/ihrer Anmeldeinformationen auffordert.

Startprozess und Sitzungsinformationen(Klicken Sie zum Vergrößern auf das Bild)

Anmeldeinformationsanbieter

Sogar die Anmeldearchitektur wurde in Windows Vista geändert. In früheren Versionen von Windows hat der Winlogon-Prozess die in der Registrierung angegebene GINA-DLL (Graphical Identification and Authentication) geladen, um eine Anmeldebenutzeroberfläche anzuzeigen, die den Benutzer zur Angabe der Anmeldeinformationen aufforderte. Leider weist das GINA-Modell eine Reihe von Einschränkungen auf, einschließlich der Tatsache, dass nur eine GINA konfiguriert werden kann, das Schreiben einer vollständigen GINA für Drittanbieter schwierig ist und dass benutzerdefinierte GINAs, die keine standardmäßigen Benutzeroberflächen haben, die Windows-Benutzerfunktionalität verändern.

Statt GINA verwendet Windows Vista die neue Anmeldeinformationsarchitektur. Winlogon startet einen getrennten Prozess, den „Logon User Interface Host“ (Logonui.exe), der die Anmeldeinformationsanbieter lädt, die in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers konfiguriert sind. LogonUI kann mehrere Anmeldeinformationsanbieter gleichzeitig hosten. Die interaktiven Anbieter (Authui.dll) und Smartcardanbieter (Smart-cardcredentialprovider.dll) sind im Lieferumfang von Windows Vista enthalten. Um eine einheitliche Benutzerfunktionalität zu gewährleisten, verwaltet LogonUI die Benutzeroberfläche, die den Endbenutzern angezeigt wird, doch sie ermöglicht außerdem den Anmeldeinformationsanbietern, benutzerdefinierte Elemente wie Text, Symbole und Bearbeitungssteuerelemente anzugeben.

Verzögerte Autostartdienste

Wenn Sie sich schon einmal bei einem Windows-System sofort nach Systemstart angemeldet haben, werden Sie die zeitliche Verzögerung bemerkt haben, bis Ihr Desktop vollständig konfiguriert ist und Sie mit der Shell und beliebigen Anwendungen, die Sie starten, interagieren können. Während Sie sich anmelden, startet der Dienststeuerungs-Manager viele Windows-Dienste, die als automatische Startdienste konfiguriert sind und deshalb zur Startzeit aktiviert werden. Viele Dienste führen CPU- und datenträgerintensive Initialisierungen durch, die mit Ihren Anmeldeaktivitäten konkurrieren. Um dies zu berücksichtigen, führt Windows Vista einen neuen Dienststarttyp ein, der sich verzögerter automatischer Start nennt und den die Dienste verwenden können, wenn sie nicht sofort nach dem Windows-Start aktiv sein müssen.

Der Dienststeuerungs-Manager startet Dienste, die für den verzögerten automatischen Start konfiguriert wurden, nachdem das Starten der Autostartdienste abgeschlossen ist, und er legt die Priorität ihres anfänglichen Threads auf THREAD_PRIORITY_LOWEST fest. Diese Prioritätsebene führt dazu, dass alle Datenträger-E/A-Vorgänge, die der Thread durchführt, eine sehr niedrige E/A-Priorität erhalten. Nachdem ein Dienst das Initialisieren abgeschlossen hat, legt der Dienststeuerungs-Manager seine Priorität auf normal fest. Diese Kombination von verschobenem Start, der niedrigen CPU- und Speicherpriorität sowie der Hintergrunddatenträgerpriorität vermindert deutlich die Beeinträchtigung der Benutzeranmeldung. Viele Windows-Dienste, einschließlich der intelligenten Hintergrundübertragung, Windows Update-Client und Windows Media® Center, verwenden den neuen Starttyp, um die Leistung der Anmeldungen nach dem Systemstart zu verbessern.

Herunterfahren

Ein Problem, das die Programmierer von Windows-Diensten geplagt hat, bestand darin, dass ihnen beim Herunterfahren von Windows in der Regel höchstens zwanzig Sekunden zur Verfügung stehen, um eine Bereinigung durchzuführen. Die Versionen vor Windows Vista haben ein sauberes Herunterfahren, das wartet, bis alle Dienste beendet sind, nicht unterstützt, weil ein umständlicher Dienst das Herunterfahren endlos aufhalten kann. Einige Dienste, wie beispielsweise jene, die über netzwerkbezogene Vorgänge zum Herunterfahren verfügen oder große Datenmengen auf Datenträger speichern müssen, benötigen möglicherweise mehr Zeit, und deshalb ermöglicht Windows Vista, dass ein Dienst eine Benachrichtigung vor dem Herunterfahren anfordern kann.

Wenn Windows Vista heruntergefahren wird, benachrichtigt der Dienststeuerungs-Manager zuerst die Dienste, die eine Benachrichtigung vor dem Herunterfahren angefordert haben. Er wartet für unbegrenzte Zeit, bis diese Dienste beendet sind, doch wenn sie einen Fehler haben und auf seine Abfragen nicht antworten, gibt der Dienststeuerungs-Manager auf und fährt nach drei Minuten fort. Nachdem diese Dienste beendet wurden oder die Zeitsperre abgelaufen ist, fährt der Dienststeuerungs-Manager fort, indem er die restlichen Dienste auf die alte Art herunterfährt. Die Gruppenrichtlinie und Windows Update Services registrieren die Benachrichtigung vor dem Herunterfahren in einer neuen Windows Vista-Installation.

Die Gruppenrichtlinie und die Windows Update Services verwenden außerdem ein anderes Windows Vista-Dienstfeature: die Reihenfolge beim Herunterfahren. Dienste konnten schon immer Startabhängigkeiten angeben, die der Dienststeuerungs-Manager Startdiensten in einer ihnen dienlichen Reihenfolge gewährt, doch in Versionen vor Windows Vista konnten sie keine Abhängigkeiten für das Herunterfahren angeben. Jetzt können sich Dienste, die sich für die Benachrichtigung vor dem Herunterfahren registrieren, außerdem für die in HKLM\System\CurrentControlSet\Control\PreshutdownOrder gespeicherte Liste registrieren. Dann beendet der Dienststeuerungs-Manager sie in der entsprechenden Reihenfolge. Weitere Informationen zu diesen Diensten erhalten Sie in der Randleiste unter „Erkennen eines verzögerten Autostarts und Dienste zur Unterstützung vor dem Herunterfahren".

Energieverwaltung

Standby und Ruhezustand sind andere Arten des Herunterfahrens, und die umständliche Energieverwaltung in Treibern und Anwendungen hat schon Probleme bereitet, seit Windows 2000 die Energieverwaltung in der Windows NT®-basierten Reihe der Windows-Betriebssysteme eingeführt hat. Viele Benutzer gingen davon aus, dass ihr Laptopsystem in den Ruhezustand wechselt oder unterbrochen wird, wenn Sie den Laptop schließen, bevor sie sich auf den Weg machen. Am Ziel wurden sie dann mit einer überhitzten Tragetasche, einer abgelaufenen Batterie und einem Verlust von Daten konfrontiert. Das lag daran, dass Windows die Gerätetreiber und Anwendungen immer um ihre Zustimmung gefragt hat, um den Betriebszustand zu ändern. Dabei konnte ein einziger Treiber oder eine einzige Anwendung, die nicht reagierte, den Übergang verhindern.

In Windows Vista informiert der Power Manager des Kernels nach wie vor die Treiber und Anwendungen über die Energiestatusänderungen, sodass sie sich darauf vorbereiten können, doch er benötigt keine Berechtigung mehr. Außerdem wartet der Power Manager höchstens 20 Sekunden, bis die Anwendungen auf die Änderungsbenachrichtigungen reagieren, statt der zwei Minuten, die er in älteren Versionen von Windows gewartet hat. Daher können Windows Vista-Benutzer jetzt mehr Vertrauen haben, dass ihre Systeme Ruhezustände und Unterbrechungen berücksichtigen.

Ausblick

Wie bereits erwähnt ist dies der zweite Teil einer dreiteiligen Artikelreihe. Im ersten Teil wurden die Verbesserungen am Windows Vista-Kernel in den Bereichen E/A-Vorgänge und Prozesse behandelt. In diesem Teil wurden die Verbesserungen in Windows Vista im Bereich Speicherverwaltung, Systemstart und Herunterfahren betrachtet. Im nächsten Teil wird die Reihe abgeschlossen mit einer Beschreibung der Änderungen, die am Kernel im Bereich Zuverlässigkeit und Sicherheit vorgenommen wurden.

Erkennen eines verzögerten Autostarts und Dienste zur Unterstützung vor dem Herunterfahren

Der integrierte SC-Befehl wurde in Windows Vista aktualisiert, um Dienste anzuzeigen, die als verzögerte Autostartdienste konfiguriert wurden:

Verwenden von SC zur Anzeige des Starttyps(Klicken Sie zum Vergrößern auf das Bild)

Leider werden vom SC-Befehl Dienste, die eine Benachrichtigung vor dem Herunterfahren angefordert haben, nicht protokolliert, doch Sie können das PsService-Dienstprogramm von Sysinternals verwenden, um zu erkennen, ob ein Dienst eine Benachrichtigung vor dem Herunterfahren akzeptiert:

Anzeigen des Status vor dem Herunterfahren(Klicken Sie zum Vergrößern auf das Bild)

Mark Russinovich ist Technical Fellow in der Platform and Services Division von Microsoft. Er ist Mitautor von „Microsoft Windows Internals“ (Microsoft Press, 2004) und hält häufig Vorträge auf IT- und Entwicklerkonferenzen. Er wechselte bei der kürzlichen Übernahme des von ihm mitgegründeten Unternehmens Winternals Software zu Microsoft. Darüber hinaus gründete er Sysinternals, wo er die Dienstprogramme „Process Explorer“, „Filemon“ und „Regmon“ veröffentlichte.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.