Komponenten der Windows-Hardwarefehlerarchitektur

Das folgende Diagramm zeigt die Hauptkomponenten der Windows Hardware Error Architecture (WHEA).

Diagramm zur Veranschaulichung von Beziehungen zwischen einem Änderungstreiber, Anwendungen und Diensten im Benutzermodus, Massenspeicher- und Porttreibern und einem Änderungsgerät.

Für jede vom Betriebssystem ermittelte Hardwarefehlerquelle gibt es einen entsprechenden niedrigstufigen Hardwarefehlerhandler (LLHEH). Ein LLHEH ist der erste Betriebssystemcode, der als Reaktion auf eine Hardwarefehlerbedingung ausgeführt wird. Eine LLHEH kann ein Interrupthandler, ein Ausnahmehandler, eine Abrufroutine oder eine Rückrufroutine sein, die von der Systemfirmware aufgerufen wird. Jede LLHEH wird im geeignetsten Softwaremodul implementiert: für E/A-Busse existieren sie in ihren jeweiligen Bustreibern; für Plattform-Fallhandler befinden sie sich im Kernel des Betriebssystems oder in der Hardwareabstraktionsebene (HAL).

Jede LLHEH führt die folgenden Aufgaben aus:

  • Erkennt den Hardwarefehler an.

  • Erfasst die verfügbaren Fehlerinformationen im Zusammenhang mit dem Hardwarefehler.

  • Meldet die Hardwarefehlerbedingung an das Betriebssystem.

Normalerweise interagieren LLHEHs direkt mit der Hardware und Firmware, um Hardwarefehlerinformationen abzurufen. LLHEHs kompilieren alle Informationen zu einem Hardwarefehler in ein Hardwarefehlerpaket. In Situationen, in denen die Firmware zunächst einen Hardwarefehler verarbeitet, interagiert die entsprechende LLHEH mit der Firmware, um das Fehlerpaket abzurufen. Alle LLHEHs melden Hardwarefehler an den Windows-Betriebssystem-Kernel, indem die Hardwarefehlerpaketdaten an eine gängige Fehlerberichterstattungsfunktion übergeben werden.

Sowohl die LLHEHs als auch der Windows-Kernel nutzen die Dienste des plattformspezifischen Hardwarefehlertreibers (PSHED), um plattformspezifische Fehlerinformationen zu sammeln. Das PSHED bietet eine Abstraktion der Hardwarefehlerberichterstattungseinrichtungen der zugrunde liegenden Plattform, indem die Details der Fehlerbehandlungsmechanismen einer Plattform vom Betriebssystem ausgeblendet und eine konsistente Schnittstelle für das Windows-Betriebssystem verfügbar sind. Auf Plattformen, die eine Systemfirmwareschnittstelle zu Hardwarefehlerbehandlungsressourcen haben, übernimmt PSHED die Schnittstelle mit der Firmware. Auf diese Weise können die Kernkomponenten von Windows nur auf die Fehlerstatusregister zugreifen, die als architekturspezifisch betrachtet werden, und gleichzeitig einen Mechanismus bereitstellen, über den umfassendere und detailliertere plattformspezifische Hardwarefehlerinformationen abgerufen werden können.

Für jede Prozessorarchitektur (x86, x64 und Itanium) stellt Microsoft einen PSHED bereit, der das grundlegende Verhalten zur Fehlerbehandlung implementiert, das für diese Architektur üblich ist. Plattformanbieter können die standardmäßige PSHED-Funktionalität ergänzen, indem PSHED-Plug-Ins bereitgestellt werden, die plattformspezifische Funktionen nutzen. Ein PSHED-Plug-In ist ein spezieller Windows-Gerätetreiber, der eine Rückrufschnittstelle implementiert, die von PSHED aufgerufen wird. Der Zweck eines PSHED-Plug-Ins besteht darin, das Standardverhalten der von Microsoft bereitgestellten PSHED zu erweitern oder außer Kraft zu setzen.

Ein PSHED-Plug-In soll von Plattformanbietern als Softwareschnittstelle für die Hardware-Fehlerberichterstattungs- und Wiederherstellungsfunktionen der Hardwareplattform implementiert werden. Ein PSHED-Plug-In kann eine Schnittstelle mit der Plattformfirmware herstellen, indem private Schnittstellen oder Mechanismen verwendet werden, die vom Plattformanbieter definiert werden. Auf diese Weise kann der Plattformanbieter weiterhin vorhandene Firmware für die Hardwarefehlerbehandlung verwenden. In der Zeit erwartet Microsoft, dass mehr Hardwarefehlerberichterstattungs- und Wiederherstellungsfunktionen standardisiert werden. Daher wird die Notwendigkeit von PSHED-Plug-Ins für die allgemeine Fehlerbehandlung und -berichterstellung verringert, sodass PSHED-Plug-Ins nur für die Unterstützung von herstellerspezifischen Features erforderlich sind, die über die standardmäßige Hardwarefehlerbehandlungsfunktionalität hinausgehen.

Weitere Informationen zum Implementieren eines PSHED-Plug-Ins finden Sie unter Platform-Specific Hardwarefehlertreiber-Plug-Ins.

Bei der Benachrichtigung durch eine LLHEH einer Hardwarefehlerbedingung erstellt Windows einen Fehlerdatensatz in einem standardisierten Format, das die Hardwarefehlerbedingung beschreibt. Windows ruft dann PSHED auf, damit dem Fehlerdatensatz zusätzliche Hardwarefehlerinformationen hinzugefügt werden können, um die Hardwarefehlerbedingung besser zu beschreiben. Wenn ein PSHED-Plug-In installiert und registriert ist, um an der Fehlerinformationserfassung teilzunehmen, ruft das PSHED seinerseits das PSHED-Plug-In auf, damit die Informationen im Fehlerdatensatz zusätzlich ergänzt werden können. Nachdem Windows alle Hardwarefehlerinformationen in den Fehlerdatensatz kompiliert hat, protokolliert es die Fehlerinformationen im Systemereignisprotokoll und benachrichtigt Benutzermodusanwendungen durch Auslösen eines Ereignisablaufverfolgungsereignisses für Windows (ETW).

Unter bestimmten Hardwarefehlerbedingungen wird das Betriebssystem gezwungen, das System neu zu starten, um den Fehler wiederherzustellen. In diesen Situationen protokolliert Windows die Fehlerinformationen nicht im Systemereignisprotokoll oder benachrichtigt Anwendungen im Benutzermodus, bis das System neu gestartet wurde. Daher muss das Betriebssystem den Fehlerdatensatz vor dem Neustart des Systems in einer Form nicht unvolatiler Speicher speichern. Das PSHED stellt eine Schnittstelle bereit, über die das Betriebssystem einen Fehlerdatensatz speichern und abrufen kann, sodass die Fehlerinformationen während des Systemneustarts erhalten bleiben. Wenn ein PSHED-Plug-In installiert und registriert ist, um an der Persistenz des Fehlerdatensatzes teilzunehmen, kann das PSHED-Plug-In eine plattformspezifische Implementierung zum Speichern und Abrufen von Fehlerdatensätzen bereitstellen. Wenn das System neu gestartet wird, ruft das Betriebssystem den gespeicherten Fehlerdatensatz ab, sodass er ordnungsgemäß im Systemereignisprotokoll protokolliert werden kann und Anwendungen im Benutzermodus benachrichtigt werden können.

Weitere Informationen dazu, wie WHEA Hardwarefehler verarbeitet, finden Sie unter "Fehlerverarbeitung".

Windows stellt außerdem eine Hardwarefehlerverwaltungs-API bereit, sodass Benutzermodusfehlerverwaltungsanwendungen Hardwarefehlerquelleninformationen festlegen und abrufen können, die Fehlerbehandlung für eine bestimmte Fehlerquelle konfigurieren und Hardwarefehler zu Testzwecken in die Hardwareplattform einfügen können.

Weitere Informationen zum Implementieren einer WHEA-Verwaltungsanwendung finden Sie unter WHEA Management Applications.