Felsökningsguide för felsökning av datafel och diskfel

  • Artikel

Skadade data och diskfel omfattar olika områden, till exempel problem med åtkomst till en enhet, skadade enheter och långsamma prestanda.

Följande händelse-ID anger att det finns skadade data eller ett diskfel:

  • Händelse-ID 153

    I/O-åtgärden på den logiska blockadressen 123456 för Disk 2 gjordes ett nytt försök.

  • Händelse-ID 129

    Återställning till enhet, \Device\RaidPort1, utfärdades.

  • Händelse-ID 157

    Disk 2 har tagits bort som överraskning.

  • Händelse-ID 55

    Filsystemstrukturen på disken är skadad och oanvändbar. Kör verktyget chkdsk på volymen.

  • Händelse-ID 98

    Volym C: (\Device\HarddiskVolume3) måste tas offline för att utföra en Fullständig Chkdsk. Kör "CHKDSK /F" lokalt via kommandoraden eller kör "REPAIR-VOLUME <drive:>" lokalt eller via en fjärranslutning via PowerShell.

Checklista för felsökning

Obs!

I den här artikeln beskrivs kommandon som måste köras i en upphöjd kommandotolk.

  • I händelseloggen System söker du efter NTFS (New Technology File System) och diskrelaterade varningar och fel. Till exempel händelse-ID 55, 153 eller 98.

  • chkdsk /scan Kör kommandot och kontrollera resultatet.

    Obs!

    Kommandot chkdsk /scan är skrivskyddat.

  • Fråga en enhet efter NTFS-specifik volyminformation genom att köra följande kommando:

    fsutil fsinfo ntfsinfo <rootpath>:

    Obs!

    Platshållarrotsökvägen <> representerar enhetsbeteckningen för rotenheten.

  • fsutil dirty query <volumepath>: Kör kommandot för att kontrollera om volymen är felaktig.

    Obs!

    Platshållarvolymen <> representerar enhetsbeteckningen.

    • För en volym vars filsystem är NTFS kör chkdsk /f /r du kommandot om volymen är felaktig. Kommandot chkdsk /F /R behöver stilleståndstid eftersom disken inte är tillgänglig.

    • För en volym vars filsystem är ReFS (Resilient File System) repareras diskskadan automatiskt.

  • Om verktyget "chkdsk" inte åtgärdar diskfelen utför du en återställning från en säkerhetskopia.

  • Kör en lagringsverifiering för att kontrollera om det finns några lagringsrelaterade fel.

  • Ta bort diskarna från klustret och kontrollera operativsystemnivån.

  • chkdsk /f Kör kommandot på alla volymer som händelsen loggas för.

  • Uppdatera lagringsdrivrutiner eller inbyggd programvara från tredje part.

Om problemet kvarstår kan du prova följande metoder:

  • Avinstallera alla diskhanteringsprogram från tredje part (till exempel Diskeeper).

  • Ta bort eller uppdatera filterdrivrutiner.

  • Kontakta maskinvaruleverantören och kör maskinvarudiagnostik för att undvika eventuella maskinvaruproblem.

  • Kontakta lagringsleverantören för att kontrollera konfigurationen för multipathing.

  • Uppdatera SCSI-porten eller RAID-styrenhetsdrivrutinerna.

  • Växla till olika typer av drivrutiner. Till exempel RAID-styrenhetsdrivrutiner eller monolitiska drivrutiner.

  • Uppdatera HBA-drivrutinerna (Host Bud Adapter).

  • Uppdatera multipathing-drivrutinerna för enhetsspecifika moduler (DSM).

  • Uppdatera den inbyggda HBA-programvaran.

Felsöka händelse-ID 153

Händelse-ID 153 anger att det finns ett fel med underlagringssystemet. Händelse-ID 153 liknar händelse-ID 129, men skillnaden är att händelse-ID 129 loggas när Storport-drivrutinen överskrider en begäran till disken och händelse-ID 153 loggas när Storport-miniportdrivrutinen överskrider en begäran. Miniportdrivrutinen kan också kallas en adapterdrivrutin eller HBA-drivrutin, som vanligtvis skrivs av maskinvaruleverantören.

Om händelse-ID 153 eller händelse-ID 129 loggas är disk-I/O-timeout den vanligaste orsaken eftersom lagringsstyrenheten inte kan hantera belastningen. I det här fallet överskrids tidsgränsen för I/O-åtgärden och miniportdrivrutinen (från en leverantör) skickar tillbaka meddelandena till Storport-drivrutinen (den sista Microsoft-lagringsdrivrutinen i stacken). Sedan översätter Storport-drivrutinen informationen och loggar händelsen i Loggboken.

Eftersom miniportdrivrutinen har tillräcklig kunskap om körningsmiljön för begäran, tar vissa miniportdrivrutiner själva begäran i stället för att låta Storport-drivrutinen hantera tidsinställningar för begäran. Miniportdrivrutinen kan avbryta en enskild begäran och returnera ett fel, medan Storport-drivrutinen återställer enheten efter en timeout. Återställning av enheten är störande för I/O-undersystemet och kanske inte är nödvändigt om endast en begäran har överskriden tidsgräns. Miniportdrivrutinen returnerar felet till den klassdrivrutin som loggar händelse-ID 153 och försöker skicka begäran igen.

Här är ett exempel på händelse-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.

Den här händelsen anger att en begäran misslyckades och att klassdrivrutinen gjorde ett nytt försök. Inget felmeddelande loggades i den här situationen eftersom Storport-drivrutinen inte översåg begäran. Bristen på meddelanden resulterade i förvirring vid felsökning av diskfel eftersom det inte fanns några bevis för felet.

På fliken Information i händelseloggen visas den detaljerade informationen om felet som orsakade återförsöket och om begäran var en läs- eller skrivbegäran. Till exempel:

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             ...*

I det här exemplet visar byteförskjutningen 29 SCSI-statusen, byteförskjutningen 30 visar statusen för SCSI-begärandeblocket (SRB) som orsakade återförsöket och byteförskjutningen 31 visar SCSI-kommandot som försöker igen. I det här fallet är 00 SCSI-statusen (SCSISTAT_GOOD), SRB-statusen är 09 (SRB_STATUS_TIMEOUT) och SCSI-kommandot är 28 (SCSIOP_READ).

Här är de vanligaste SCSI-kommandona:

SCSIOP_READ - 0x28
SCSIOP_WRITE - 0x2A

Se scsi.h för en lista över SCSI-åtgärder och statusar.

Här är de vanligaste SRB-statusarna:

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

Se srb.h för en lista över SRB-statusar.

Obs!

  • Timeout-felen (SRB_STATUS_TIMEOUT eller SRB_STATUS_COMMAND_TIMEOUT) indikerar att en begäran överskrids i adaptern. En begäran skickades till enheten och det fanns inget svar inom tidsgränsen.

  • Felet för bussåterställning (SRB_STATUS_BUS_RESET) anger att enheten har återställts och att begäran görs på nytt på grund av återställningen eftersom alla ofullständiga begäranden avbryts när en enhet får en återställning.

En administratör måste kontrollera hälsotillståndet för diskundersystemet. Även om en tillfällig timeout kan vara en del av den normala driften av ett system, indikerar de frekventa återförsöksbegäranden ett prestandaproblem med lagring som ska åtgärdas.

Mer information

Eftersom problemet normalt ligger utanför operativsystemet kontrollerar du följande vanliga orsaker:

  • Någon typ av begränsning har konfigurerats, till exempel I/O-begränsningar. Ibland orsakar Lagrings-I/O-kontroll i VMware det här problemet.

  • För många enheter med hög belastning finns på samma lagringsstyrenhet. Därför måste enheterna delas upp mellan olika styrenheter.

  • Om MULTIPATH I/O (MPIO) har konfigurerats kan en enda kabel eller ett skadat nätverkskort orsaka problem med iSCSI.

Felsöka händelse-ID 129

Händelse-ID 129 loggas med HBA-drivrutinens namn som källa. Storport-drivrutinen (Storport.sys) loggar den här händelsen när den upptäcker att en begäran har överskriden tidsgräns. HBA-drivrutinens namn används i händelsen eftersom det är miniportdrivrutinen som är associerad med Storport-drivrutinen.

Här är ett exempel på händelse-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.

Information om Arkitektur för Windows I/O-stack

Windows I/O-åtgärden använder en arkitektur i flera lager där enhetsdrivrutiner finns på en enhetsstack. I en grundläggande modell är överst i stacken filsystemet. Nästa är volymhanteraren, följt av diskdrivrutinen. Port- och miniportdrivrutinerna finns längst ned i enhetsstacken. När en I/O-begäran når filsystemet tar den filens blocknummer och översätter den till en förskjutning i volymen. Sedan översätter volymhanteraren volymförskjutningen till ett blocknummer på disken och skickar begäran till diskdrivrutinen. När begäran når diskdrivrutinen skapas ett kommandobeskrivningsblock (CDB) och skickas till SCSI-enheten. Diskdrivrutinen bäddar in CDB i strukturen för SCSI_REQUEST_BLOCK (SRB). Denna SRB skickas till portdrivrutinen som en del av I/O-begärandepaketet (IRP).

Portdrivrutinen utför merparten av bearbetningen av begäranden. Det finns olika portdrivrutiner beroende på arkitekturen. Till exempel ATA-portdrivrutinen (Ataport.sys) och SCSI-portdrivrutinen (Storport.sys). Här följer några ansvarsområden för en portdrivrutin:

  • Tillhandahålla tidsinställningar för begäranden

  • Framtvinga ködjup för att se till att en enhet inte har fler begäranden än den kan hantera

  • Skapa "punkt- och insamlingsmatriser" för databuffertar

Portdrivrutinen har gränssnitt med miniportdrivrutinen och miniportdrivrutinen har utformats av maskinvaruleverantören för att fungera med ett specifikt kort. Den ansvarar för att ta begäranden från portdrivrutinen och skicka dem till det logiska målenhetsnumret (LUN). Portdrivrutinen anropar HwStorStartIo() funktionen för att skicka begäranden till miniportdrivrutinen, och miniportdrivrutinen skickar begäranden till HBA-drivrutinen så att de kan skickas via det fysiska mediet (Fibre eller Ethernet) till LUN. När begäran har slutförts anropar StorPortNotification() miniportdrivrutinen funktionen med parametern NotificationType med ett värde inställt på RequestComplete, tillsammans med en pekare till den slutförda SRB:en.

När en begäran skickas till miniportdrivrutinen placerar Storport-drivrutinen begäran i en väntande kö och den är tids nog. När begäran har slutförts tas den bort från den här kön.

Tidsmekanismen är enkel. Det finns en timer per logisk enhet och den initieras till -1. När den första begäran skickas till miniportdrivrutinen anges timern till timeout-värdet i SRB. Disktimeout-värdet är en justerbar parameter som finns under följande registernyckel:

HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue

Vissa maskinvaruleverantörer finjusterar det här värdet så att de bäst matchar sin maskinvara. Ändra inte det här värdet utan vägledning från lagringsleverantören.

Timern minskas en gång per sekund. När en begäran har slutförts uppdateras timern med timeout-värdet för huvudbegäran i den väntande kön. Därför kommer timern aldrig att gå till noll så länge begäranden slutförs. Om timern går till noll innebär det att enheten har slutat svara. När Storport-drivrutinen till exempel loggar händelse-ID 129 måste Storport-drivrutinen vidta korrigerande åtgärder genom att försöka återställa enheten. När enheten återställs slutförs alla ofullständiga begäranden med ett fel och de görs ett nytt försök. När den väntande kön rensas anges timern till -1, vilket är det ursprungliga värdet.

Varje SRB har ett tidsinställt värde. När begäranden har slutförts uppdateras kötimern med tidsgränsvärdet för SRB som chef för listan.

De vanligaste orsakerna till händelse-ID 129 är lun som inte svarar eller en borttagen begäran. Borttagna begäranden kan orsakas av felaktiga routrar eller andra maskinvaruproblem i san-nätverket (Storage Area Network).

Felsöka händelse-ID 157

Den här händelsen anger att Classpnp.sys-drivrutinen har fått en överraskande borttagningsbegäran från plug and play-hanteraren (PNP) för en icke-flyttbar disk.

Det här problemet uppstår oftast när något stör systemets kommunikation med en disk, till exempel ett SAN-infrastrukturfel eller ett SCSI-bussproblem. Felen kan också orsakas av en disk som misslyckas eller när en användare kopplar från en disk medan systemet körs. I det här fallet måste en administratör verifiera diskundersystemets hälsostatus.

Felsöka händelse-ID 55 och 98

Om NTFS-händelser som händelse-ID 55, 50, 140 och 98 loggas måste du köra verktyget "chkdsk".

Eftersom NTFS inte kunde skriva data till transaktionsloggen kan detta påverka möjligheten för NTFS att stoppa eller återställa de åtgärder där transaktionsdata inte kunde skrivas.

Här är ett exempel på händelse-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.

Vanligtvis loggas händelse-ID 55 när filsystemet skadas. Filsystemet skadas när ett eller flera av följande problem uppstår:

  • En disk har dåliga sektorer.

  • I/O-begäranden som levereras av filsystemet till diskundersystemet har inte slutförts.

De flesta problem är maskinvarurelaterade och maskinvaran kan skadas oväntat. Du kan prova följande metoder för att åtgärda problemen:

  • Uppdatera SCSI-porten eller RAID-styrenhetsdrivrutinerna.

  • Ta bort eller uppdatera filterdrivrutiner.

  • Uppdatera lagringsdrivrutiner eller inbyggd programvara från tredje part.

  • Växla till olika typer av drivrutiner. Till exempel RAID-styrenhetsdrivrutiner eller monolitiska drivrutiner.

  • Ordna om maskinvaran i olika kombinationer.

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.