Freigeben über

Leitfaden zur Problembehandlung bei Datenbeschädigung und Datenträgerfehlern

Datenbeschädigungen und Datenträgerfehler decken verschiedene Bereiche ab, z. B. Probleme beim Zugriff auf ein Laufwerk, Laufwerkbeschädigung und langsame Leistung.

Die folgenden Ereignis-IDs geben an, dass Datenbeschädigungen oder datenträgerfehler vorliegen:

  • Ereignis-ID 153

    Der E/A-Vorgang an der logischen Blockadresse 123456 für Datenträger 2 wurde erneut überprüft.

  • Ereignis-ID 129

    Das Zurücksetzen auf das Gerät \Device\RaidPort1 wurde ausgegeben.

  • Ereignis-ID 157

    Datenträger 2 wurde überraschend entfernt.

  • Ereignis-ID 55

    Die Dateisystemstruktur auf dem Datenträger ist beschädigt und nicht verwendbar. Führen Sie das Hilfsprogramm "chkdsk" auf dem Volume aus.

  • Ereignis-ID 98

    Volume C: (\Device\HarddiskVolume3) muss offline geschaltet werden, um einen vollständigen Chkdsk auszuführen. Führen Sie "CHKDSK /F" lokal über die Befehlszeile aus, oder führen Sie "REPAIR-VOLUME <drive:>" lokal oder remote über PowerShell aus.

Checkliste zur Problembehandlung

Notiz

In diesem Artikel werden Befehle beschrieben, die an einer Eingabeaufforderung mit erhöhten Rechten ausgeführt werden müssen.

  • Suchen Sie im Systemereignisprotokoll nach New Technology File System (NTFS) und datenträgerbezogenen Warnungen und Fehlern. Beispiel: Ereignis-ID 55, 153 oder 98.

  • Führen Sie den Befehl chkdsk /scan aus und überprüfen Sie das Ergebnis.

    Notiz

    Der chkdsk /scan Befehl ist schreibgeschützt.

  • Abfragen eines Laufwerks für NTFS-spezifische Volumeinformationen, indem Sie den folgenden Befehl ausführen:

    fsutil fsinfo ntfsinfo <rootpath>:

    Notiz

    Der Platzhalterstammpfad <> stellt den Laufwerkbuchstaben des Stammlaufwerks dar.

  • Führen Sie den fsutil dirty query <volumepath>:-Befehl aus, um zu überprüfen, ob das Volume modifiziert wurde.

    Notiz

    Der Platzhaltervolumepfad <> stellt den Laufwerkbuchstaben dar.

    • Führen Sie für ein Volume, dessen Dateisystem NTFS ist, den chkdsk /f /r-Befehl aus, wenn das Volume modifiziert ist. Der chkdsk /F /R-Befehl benötigt Ausfallzeiten, da auf den Datenträger nicht zugegriffen werden kann.

    • Für ein Volume, dessen Dateisystem Robustes Dateisystem (ReFS) ist, wird die Datenträgerbeschädigung automatisch repariert.

  • Wenn das Dienstprogramm „chkdsk“ die Festplattenfehler nicht behebt, führen Sie eine Wiederherstellung von ein Backup durch.

  • Führen Sie eine Speichervalidierung durch, um zu prüfen, ob es speicherbezogene Fehler gibt.

  • Entfernen Sie die Datenträger aus dem Cluster und überprüfen Sie die Betriebssystemebene.

  • Führen Sie den Befehl chkdsk /f auf allen Volumes aus, für die das Ereignis protokolliert wird.

  • Aktualisieren Sie die Speichertreiber oder Firmware von Drittanbietern.

Wenn das Problem weiterhin besteht, versuchen Sie die folgenden Methoden:

  • Deinstallieren Sie jegliche Festplattenverwaltungssoftware von Drittanbietern (z. B. Diskeeper).

  • Entfernen oder aktualisieren Sie die Filtertreiber.

  • Wenden Sie sich an den Hardwareanbieter, und führen Sie eine Hardwarediagnose aus, um mögliche Hardwareprobleme zu vermeiden.

  • Wenden Sie sich an den Speicheranbieter, um die Multipfadkonfiguration zu überprüfen.

  • Aktualisieren Sie den SCSI-Port oder die RAID-Controllertreiber.

  • Wechseln zu verschiedenen Typen von Treibern. Beispiel: RAID-Controllertreiber oder monolithische Treiber.

  • Aktualisieren Sie die Host Bud Adapter (HBA)-Treiber.

  • Aktualisieren Sie die Multipfad-Treiber von gerätespezifischen Modulen (DSM).

  • Aktualisieren Sie die HBA-Firmware.

Problembehandlung bei Ereignis-ID 153

Die Ereignis-ID 153 gibt an, dass beim Speichersubsystem ein Fehler auftritt. Die Ereignis-ID 153 ähnelt der Ereignis-ID 129, der Unterschied besteht jedoch darin, dass die Ereignis-ID 129 protokolliert wird, wenn der Storport-Treiber eine Anforderung an die Festplatte unterbricht, während die Ereignis-ID 153 protokolliert wird, wenn der Storport-Miniport-Treiber eine Anforderung unterbricht. Der Miniporttreiber kann auch als Adaptertreiber oder HBA-Treiber bezeichnet werden, der in der Regel vom Hardwareanbieter geschrieben wird.

Wenn ereignis-ID 153 oder Ereignis-ID 129 protokolliert wird, ist datenträger-E/A-Timeout die häufige Ursache, da der Speichercontroller die Last nicht verarbeiten kann. In diesem Fall ist der E/A-Vorgang ausfällt, und der Miniporttreiber (von einem Anbieter) sendet die Nachrichten an den Storport-Treiber (der letzte Microsoft-Speichertreiber im Stapel). Anschließend übersetzt der Storport-Treiber die Informationen und protokolliert das Ereignis im Ereignisanzeige.

Da der Miniport-Treiber über ausreichende Kenntnisse der Anforderungsausführungsumgebung verfügt, müssen einige Miniporttreiber die Anforderung selbst zeitigen, anstatt dem Storport-Treiber die Anforderungsanzeigedauer zu ermöglichen. Der Miniporttreiber kann eine einzelne Anforderung abbrechen und einen Fehler zurückgeben, während der Storport-Treiber das Laufwerk nach einem Timeout zurücksetzt. Das Zurücksetzen des Laufwerks ist störend für das E/A-Subsystem und kann nicht erforderlich sein, wenn nur eine Anforderung ein Timeout erreicht hat. Der Miniporttreiber gibt den Fehler an den Klassentreiber zurück, der die Ereignis-ID 153 protokolliert und die Anforderung erneut anzeigt.

Hier ist ein Beispiel für die Ereignis-ID 153:

Log Name: System
Source: disk
Event ID: 153
Level: Warning
Description: The IO operation at logical block address 123456 for Disk 2 was retried.

Dieses Ereignis gibt an, dass eine Anforderung fehlgeschlagen ist und vom Klassentreiber erneut überprüft wurde. In dieser Situation wurde keine Fehlermeldung protokolliert, da der Storport-Treiber die Anforderung nicht ausgezeit hat. Der Mangel an Nachrichten führte zu Verwirrung bei der Problembehandlung von Datenträgerfehlern, da kein Nachweis für den Fehler aufgetreten ist.

Auf der Registerkarte "Details " des Ereignisprotokolls zeigen die detaillierten Informationen den Fehler an, der den Wiederholungsvorgang verursacht hat und ob es sich bei der Anforderung um eine Lese- oder Schreibanforderung handelt. Zum Beispiel:

0000: 0004010F 002C0003 00000000 80040099
0010: 00000000 00000000 00000000 00000000
0020: 00000000 00000000 28090000

in bytes

0000: 0F 01 04 00 03 00 2C 00 ......,.
0008: 00 00 00 00 99 00 04 80 ......
0010: 00 00 00 00 00 00 00 00 ........
0018: 00 00 00 00 00 00 00 00 ........
0020: 00 00 00 00 00 00 00 00 ........
0028: 00 00 09 28             ...*

In diesem Beispiel zeigt der Byte-Offset 29 den SCSI-Status an, der Byte-Offset 30 zeigt den SCSI-Anforderungsblockstatus (SRB) an, der den Wiederholungsversuch verursacht hat, und der Byte-Offset 31 zeigt den SCSI-Befehl an, der erneut überprüft wird. In diesem Fall lautet 00 der SCSI-Status (SCSISTAT_GOOD), der SRB-Status (09SRB_STATUS_TIMEOUT) und der SCSI-Befehl ist 28 (SCSIOP_READ).

Hier sind die am häufigsten verwendeten SCSI-Befehle:

SCSIOP_READ - 0x28
SCSIOP_WRITE - 0x2A

Eine Liste der SCSI-Vorgänge und -Status finden Sie unter scsi.h .

Hier sind die am häufigsten verwendeten SRB-Status:

SRB_STATUS_TIMEOUT - 0x09
SRB_STATUS_BUS_RESET - 0x0E
SRB_STATUS_COMMAND_TIMEOUT - 0x0B

Eine Liste der SRB-Status finden Sie unter srb.h .

Notiz

  • Die Timeoutfehler (SRB_STATUS_TIMEOUT oder SRB_STATUS_COMMAND_TIMEOUT) deuten darauf hin, dass eine Anforderung im Adapter timeout ist. Eine Anforderung wurde an das Laufwerk gesendet, und es gab keine Antwort innerhalb des Timeoutzeitraums.

  • Der Buszurücksetzungsfehler (SRB_STATUS_BUS_RESET) gibt an, dass das Gerät zurückgesetzt wurde und die Anforderung aufgrund der Zurücksetzung erneut ausgeführt wird, da alle unvollständigen Anforderungen abgebrochen werden, wenn ein Laufwerk eine Zurücksetzung empfängt.

Ein Administrator muss die Integrität des Datenträgersubsystems überprüfen. Obwohl ein gelegentlicher Timeout Teil des normalen Betriebs eines Systems sein kann, weisen die häufigen Wiederholungsanforderungen auf ein Leistungsproblem mit Speicher hin, das behoben werden sollte.

Weitere Informationen

Da das Problem normalerweise außerhalb des Betriebssystems liegt, überprüfen Sie die folgenden allgemeinen Ursachen:

  • Einige Arten von Drosselung sind konfiguriert, z. B. E/A-Einschränkungen. Manchmal verursacht die Speicher-E/A-Steuerung in VMware dieses Problem.

  • Zu viele Laufwerke mit hoher Last befinden sich auf demselben Speichercontroller. Daher müssen die Laufwerke auf verschiedene Controller aufgeteilt werden.

  • Wenn Multipath I/O (MPIO) konfiguriert ist, kann ein einzelnes Kabel oder eine beschädigte NIC Probleme mit iSCSI verursachen.

Problembehandlung bei Ereignis-ID 129

Ereignis-ID 129 wird mit dem Namen des Speicheradapters (HBA) als Quelle protokolliert. Der Storport-Treiber (Storport.sys) protokolliert dieses Ereignis, wenn erkannt wird, dass eine Anforderung timeout ist. Der Name des HBA-Treibers wird im Ereignis verwendet, da es sich um den Miniporttreiber handelt, der dem Storport-Treiber zugeordnet ist.

Hier ist ein Beispiel für die Ereignis-ID 129:

Event Type:       Warning
Event Source:     <HBA_Name>
Event Category:   None
Event ID:         129
Computer:         <Computer_Name>
Description: Reset to device, \Device\RaidPort1, was issued.

Informationen zur Windows-I/O-Stapelarchitektur

Der Windows-E/A-Vorgang verwendet eine mehrschichtige Architektur, bei der Gerätetreiber sich auf einem Gerätestapel befinden. In einem einfachen Modell ist der oberste Teil des Stapels das Dateisystem. Als Nächstes befindet sich der Volume-Manager, gefolgt vom Datenträgertreiber. Die Port- und Miniporttreiber befinden sich am unteren Rand des Gerätestapels. Wenn eine E/A-Anforderung das Dateisystem erreicht, wird die Blocknummer der Datei in einen Offset im Volume übersetzt. Anschließend übersetzt der Volume-Manager den Volumeoffset in eine Blocknummer auf dem Datenträger und übergibt die Anforderung an den Datenträgertreiber. Wenn die Anforderung den Datenträgertreiber erreicht, wird ein Befehlsdeskriptorblock (CDB) erstellt und an das SCSI-Gerät gesendet. Der Datenträgertreiber bettet das CDB in die SCSI_REQUEST_BLOCK(SRB)-Struktur ein. Dieser SRB wird als Teil des E/A-Anforderungspakets (IRP) an den Porttreiber gesendet.

Der Porttreiber führt den Großteil der Anforderungsverarbeitung durch. Die Porttreiber unterscheiden sich je nach Architektur. Beispielsweise der ATA-Porttreiber (Ataport.sys) und der SCSI-Porttreiber (Storport.sys). Hier sind einige Zuständigkeiten eines Porttreibers:

  • Bereitstellen von Zeitangaben für Anforderungen

  • Erzwingen der Warteschlangentiefe, um sicherzustellen, dass ein Gerät nicht mehr Anforderungen hat, als es verarbeiten kann

  • Erstellen von Punkt- und "Gather"-Arrays für Datenpuffer

Die Porttreiberschnittstellen mit dem Miniporttreiber und der Miniporttreiber werden vom Hardwareanbieter für die Arbeit mit einem bestimmten Adapter entworfen. Sie ist dafür verantwortlich, Anforderungen vom Porttreiber zu übernehmen und sie an die Ziel-Logische Einheitsnummer (LUN) zu senden. Der Porttreiber ruft die HwStorStartIo() Funktion zum Senden von Anforderungen an den Miniporttreiber auf, und der Miniporttreiber sendet die Anforderungen an den HBA-Treiber, sodass sie über das physische Medium (Fibre oder Ethernet) an das LUN gesendet werden können. Wenn die Anforderung abgeschlossen ist, ruft der Miniporttreiber die StorPortNotification() Funktion mit dem NotificationType Parameter mit einem Wert auf RequestComplete, zusammen mit einem Zeiger auf den abgeschlossenen SRB auf.

Wenn eine Anforderung an den Miniporttreiber gesendet wird, platziert der Storport-Treiber die Anforderung in einer ausstehenden Warteschlange, und es wird eine Zeitdauer festgelegt. Wenn die Anforderung abgeschlossen ist, wird sie aus dieser Warteschlange entfernt.

Der Timingmechanismus ist einfach. Es gibt einen Timer pro logische Einheit und wird initialisiert für -1. Wenn die erste Anforderung an den Miniporttreiber gesendet wird, wird der Timer auf den Timeoutwert im SRB festgelegt. Der Wert des Datenträgertimeouts ist ein tunbarer Parameter, der sich unter dem folgenden Registrierungsschlüssel befindet:

HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue

Einige Hardwareanbieter optimieren diesen Wert, um ihre Hardware optimal abzugleichen. Ändern Sie diesen Wert nicht ohne Anleitung von Ihrem Speicheranbieter.

Der Timer wird einmal pro Sekunde dekrementiert. Wenn eine Anforderung abgeschlossen ist, wird der Timer mit dem Timeoutwert der Head-Anforderung in der ausstehenden Warteschlange aktualisiert. Daher wird der Timer nie zu Null gehen, solange Die Anforderungen abgeschlossen sind. Wenn der Timer zu Null wechselt, bedeutet dies, dass das Gerät nicht mehr reagiert. Wenn der Storport-Treiber beispielsweise ereignis-ID 129 protokolliert, muss der Storport-Treiber Korrekturmaßnahmen ergreifen, indem versucht wird, die Einheit zurückzusetzen. Wenn die Einheit zurückgesetzt wird, werden alle unvollständigen Anforderungen mit einem Fehler abgeschlossen, und sie werden wiederholt. Wenn die ausstehende Warteschlange gelöscht wird, wird der Timer auf -1,, die der Anfangswert ist.

Für jeden SRB ist ein Timerwert festgelegt. Wenn Anforderungen abgeschlossen sind, wird der Warteschlangentimer mit dem Timeoutwert des SRB an der Kopfzeile der Liste aktualisiert.

Die häufigsten Ursachen für Ereignis-ID 129 sind nicht reagierende LUNs oder eine gelöschte Anforderung. Verworfene Anforderungen können durch fehlerhafte Router oder andere Hardwareprobleme im Speicherbereichsnetzwerk (SAN) verursacht werden.

Problembehandlung bei Ereignis-ID 157

Dieses Ereignis gibt an, dass der Classpnp.sys Treiber eine Überraschungsentfernungsanforderung vom Plug and Play Manager (PNP) für einen nicht wechselbaren Datenträger erhalten hat.

Dieses Problem tritt am häufigsten auf, wenn die Kommunikation des Systems mit einem Datenträger unterbrochen wird, z. B. ein SAN-Fabric-Fehler oder ein SCSI-Busproblem. Die Fehler können auch durch einen Datenträger verursacht werden, der fehlschlägt oder wenn ein Benutzer einen Datenträger entkoppelt, während das System ausgeführt wird. In diesem Fall muss ein Administrator die Heide des Datenträgersubsystems überprüfen.

Problembehandlung bei Ereignis-ID 55 und 98

Wenn NTFS-Ereignisse wie Ereignis-ID 55, 50, 140 und 98 protokolliert werden, müssen Sie das Hilfsprogramm "chkdsk" ausführen.

Da NTFS keine Daten in das Transaktionsprotokoll schreiben konnte, konnte dies die Fähigkeit von NTFS beeinträchtigen, die Operationen zu stoppen oder zurückzusetzen, bei denen die Transaktionsdaten nicht geschrieben werden konnten.

Hier ist ein Beispiel für ereignis-ID 55:

Event Type: Error
Event Source: NTFS
Event ID: 55
Description: The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume.

In der Regel wird ereignis-ID 55 protokolliert, wenn Dateisystembeschädigung auftritt. Die Dateisystembeschädigung tritt auf, wenn mindestens eins der folgenden Probleme auftritt:

  • Ein Datenträger verfügt über ungültige Sektoren.

  • E/A-Anforderungen, die vom Dateisystem an das Datenträgersubsystem übermittelt werden, werden nicht erfolgreich abgeschlossen.

Die meisten Probleme sind hardwarebezogen, und Die Hardware ist unerwartet beschädigt. Sie können die folgenden Methoden ausprobieren, um die Probleme zu beheben:

  • Aktualisieren Sie den SCSI-Port oder die RAID-Controllertreiber.

  • Entfernen oder aktualisieren Sie die Filtertreiber.

  • Aktualisieren Sie die Speichertreiber oder Firmware von Drittanbietern.

  • Wechseln zu verschiedenen Typen von Treibern. Beispiel: RAID-Controllertreiber oder monolithische Treiber.

  • Ordnen Sie Hardware in verschiedene Kombinationen um.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.