Rozwiązywanie problemów z aktualizacjami oprogramowania układowego stacji dysków

System Windows 10 w wersji 1703 i nowszej obejmuje możliwość aktualizowania oprogramowania układowego dysków HDD i dysków SSD, które zostały certyfikowane za pomocą oprogramowania układowego Upgradeable AQ (dodatkowe kwalifikator) za pośrednictwem programu PowerShell.

Więcej informacji na temat tej funkcji można znaleźć tutaj:

• Aktualizowanie oprogramowania układowego stacji dysków w systemie Windows Server 2016
• Aktualizacja oprogramowania układowego dysków w Storage Spaces Direct bez przestojów

Aktualizacje oprogramowania układowego mogą zakończyć się niepowodzeniem z różnych powodów. Celem tego artykułu jest pomoc w zaawansowanym rozwiązywaniu problemów.

Typowe problemy

Z architektonicznego punktu widzenia, ta nowa funkcjonalność opiera się na interfejsach API zaimplementowanych w stosie magazynu systemu Windows, z którego korzysta PowerShell. Stos magazynowy opiera się na sterownikach i sprzęcie do prawidłowego wdrażania poleceń zdefiniowanych przez branżę. Daje to kilka punktów, w których mogą wystąpić awarie. Najczęściej obserwowane problemy to:

• Podany dysk nie realizuje poprawnie standardowych poleceń branżowych (nie ma AQ).
• Interfejsy API potrzebne do przeprowadzenia aktualizacji nie są implementowane lub są wadliwe (jeśli są używane sterowniki innych firm).
• API działają, ale występuje problem z samym oprogramowaniem układowym (na przykład nieprawidłowy/uszkodzony plik obrazu).

W poniższych sekcjach opisano informacje dotyczące rozwiązywania problemów, w zależności od tego, czy są używane sterowniki firmy Microsoft czy innych firm.

Identyfikowanie nieodpowiedniego sprzętu

Najszybszym sposobem określenia, czy urządzenie obsługuje prawidłowy zestaw poleceń, jest uruchomienie programu PowerShell i przekazanie dysku reprezentującego obiekt PhysicalDisk do polecenia cmdlet Get-StorageFirmwareInfo. Oto przykład:

Get-PhysicalDisk -SerialNumber 15140F55976D | Get-StorageFirmwareInformation

Oto przykładowe dane wyjściowe:

PhysicalDisk          : MSFT_PhysicalDisk (ObjectId = "{1}\\TOKLIMA-DL380\root/Microsoft/Windo...)
SupportsUpdate        : True
NumberOfSlots         : 1
ActiveSlotNumber      : 0
SlotNumber            : {0}
IsSlotWritable        : {True}
FirmwareVersionInSlot : {0013}

Pole SupportsUpdate, co najmniej dla urządzeń SATA i NVMe, wskazuje, czy wbudowane funkcje programu PowerShell mogą służyć do aktualizowania oprogramowania układowego.

Pole SupportsUpdate zawsze zgłasza „True” dla urządzeń podłączonych za pomocą SAS, ponieważ wykonywanie zapytań o odpowiednią obsługę poleceń nie jest możliwe za pomocą standardowych poleceń branżowych.

Aby sprawdzić, czy urządzenie SAS obsługuje wymagany zestaw poleceń, istnieją dwie opcje:

• Przetestuj urządzenie SAS za pomocą cmdletu Update-StorageFirmware z właściwym obrazem firmware, lub
• Sprawdź katalog Windows Server, aby określić, które urządzenia SAS pomyślnie uzyskały aktualizację FW przez AQ (https://www.windowsservercatalog.com/)

Opcje korygowania

Jeśli testowane urządzenie nie obsługuje odpowiedniego zestawu poleceń, wyślij zapytanie do dostawcy, aby sprawdzić, czy zaktualizowane oprogramowanie układowe jest dostępne, które udostępnia wymagany zestaw poleceń, lub zapoznaj się z wykazem systemu Windows Server, aby zidentyfikować urządzenia do określania źródła, które implementują odpowiedni zestaw poleceń.

Rozwiązywanie problemów ze sterownikami innych firm (SAS)

Składniki oprogramowania, które bezpośrednio współdziałają ze sprzętem, to sterowniki miniportów w stosie pamięci masowej systemu Windows. W przypadku niektórych protokołów magazynu, takich jak SATA i NVMe, firma Microsoft udostępnia natywne sterowniki systemu Windows. Te sterowniki obsługują dodatkowe informacje o debugowaniu. Dostawcy sprzętu i oprogramowania innych firm mogą jednak zapisywać niestandardowe sterowniki miniportów dla swoich urządzeń. W takich przypadkach obsługa informacji debugowania może się różnić.

Aby zidentyfikować, co się stało z pobieraniem oprogramowania układowego i aktywacją interfejsów API przesyłanych w stosie pamięci masowej, niezależnie od sterownika miniportu, zapoznaj się z następującym kanałem dziennika zdarzeń:

Podgląd zdarzeń — dzienniki aplikacji i usług — Microsoft — Windows — StorDiag — Microsoft-Windows-Storage-ClassPnP/Operational

Kanał ten rejestruje informacje o interfejsach API Windows, które są wysyłane do sterowników miniportu oraz o ich odpowiedziach. Na przykład następujący warunek błędu występuje podczas próby pobrania obrazu oprogramowania układowego do urządzenia SATA podłączonego za pośrednictwem karty HBA SAS, która nieprawidłowo realizuje wymaganą translację z SAS na SATA:

Get-PhysicalDisk -SerialNumber 44GS103UT5EW | Update-StorageFirmware -ImagePath C:\Firmware\J3E160@3.enc -SlotNumber 0

Oto przykład danych wyjściowych:

Update-StorageFirmware : Failed

Extended information:
A warning or error has been encountered during storage firmware update.
Incorrect function.

Activity ID: {1224482b-2315-4a38-81eb-27bb7de19c00}
At line:1 char:47
+ ... S103UT5EW | Update-StorageFirmware -ImagePath C:\Firmware\J3E160@3.en ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Update-StorageFirmware], CimException
+ FullyQualifiedErrorId : StorageWMI 4,Microsoft.Management.Infrastructure.CimCmdlets.InvokeCimMethodCommand,Update-StorageFirmware

PowerShell zgłasza błąd i otrzymał informację, że wywołana funkcja (czyli interfejs API jądra) była niepoprawna. Błąd może oznaczać, że interfejs API nie został zaimplementowany przez sterownik mini-portu SAS innej firmy, co jest poprawne w tym przypadku, lub że interfejs API zakończył się niepowodzeniem z innego powodu, na przykład z powodu niezgodności segmentów pobierania.

EventData
DeviceGUID	{132EDB55-6BAC-A3A0-C2D5-203C7551D700}
DeviceNumber	1
Vendor	ATA
Model	TOSHIBA THNSNJ12
FirmwareVersion	6101
SerialNumber	44GS103UT5EW
DownLevelIrpStatus	0xc0000185
SrbStatus	132
ScsiStatus	2
SenseKey	5
AdditionalSenseCode	36
AdditionalSenseCodeQualifier	0
CdbByteCount	10
CdbBytes	3B0E0000000001000000
NumberOfRetriesDone	0

Zdarzenie ETW 507 z kanału, pokazuje, że żądanie SRB SCSI nie powiodło się i zawiera dodatkowe informacje: SenseKey wynosił „5” (nieprawidłowe żądanie), a dodatkowy kod AdditionalSense wynosił „36” (nieprawidłowe pole w CDB).

Istnieje możliwość, aby różne warunki błędów wykazywały te same kody błędów, jeśli sterownik miniportu ich nie rozróżnia. Na przykład próba pobrania nieprawidłowego obrazu oprogramowania układowego za pośrednictwem karty HBA SAS do urządzenia SATA (dla którego oczekiwane jest niepowodzenie) może skutkować identycznymi kodami błędów.

W przypadkach, gdy występują mieszane protokoły i translacje, czyli SATA po stronie SAS, najlepiej przetestować urządzenie SATA bezpośrednio podłączone do kontrolera SATA, aby wykluczyć możliwość, że jest to potencjalny problem.

Opcje korygowania

Jeśli sterownik innej firmy zostanie zidentyfikowany jako nieimplementujący wymaganych interfejsów API lub konwersji, można zamienić na alternatywy dostarczone przez Microsoft dla SATA (StorAHCI.sys) i NVMe (StorNVMe.sys) lub skontaktować się z dostawcą OEM lub HBA, który zapewnił sterownik SAS, aby zapytać, czy istnieje nowsza wersja z odpowiednią obsługą.

Więcej problemów z sterownikami firmy Microsoft (SATA/NVMe)

W przypadku sterowników natywnych dla systemu Windows, takich jak StorAHCI.sys lub StorNVMe.sys używanych do zasilania urządzeń magazynujących, można uzyskać dodatkowe informacje o możliwych przypadkach awarii podczas operacji aktualizacji oprogramowania układowego.

Poza kanałem operacyjnym ClassPnP, StorAHCI i StorNVMe rejestrują kody powrotne specyficzne dla protokołu urządzenia w następującym kanale ETW:

Podgląd zdarzeń — dzienniki aplikacji i usług — Microsoft — Windows — StorDiag — Microsoft-Windows-Storage-StorPort/Diagnose

Dzienniki diagnostyczne nie są domyślnie wyświetlane i można je aktywować/pokazać, wybierając pozycję "Wyświetl" w programie EventViewer, a następnie wybierając pozycję "Pokaż dzienniki analizy i debugowania" z menu rozwijanego.

Aby zebrać te zaawansowane wpisy dziennika, włącz dziennik, odtwórz błąd aktualizacji oprogramowania układowego i zapisz dziennik diagnostyczny.

Oto przykład aktualizacji oprogramowania układowego na urządzeniu SATA, który kończy się niepowodzeniem, ponieważ obraz do pobrania był nieprawidłowy (identyfikator zdarzenia: 258):

EventData
MiniportName	storahci
MiniportEventId	19
MiniportEventDescription	Firmware Activate Completion
PortNumber	0
Bus	2
Target	0
LUN	0
Irp	0xffff8c84cd45aca0
Srb	0xffffab0024030bc0
Parameter1Name	SrbStatus
Parameter1Value	130
Parameter2Name	ReturnCode
Parameter2Value	0
Parameter3Name	FeaturesReg
Parameter3Value	15
Parameter4Name	SectorCountReg
Parameter4Value	0
Parameter5Name	DriveHeadReg
Parameter5Value	160
Parameter6Name	CommandReg
Parameter6Value	146
Parameter7Name	NULL
Parameter7Value	0
Parameter8Name	NULL
Parameter8Value	0

Powyższe zdarzenie zawiera szczegółowe informacje o urządzeniu w wartościach parametrów od 2 do 6. W tym miejscu przyjrzymy się różnym wartościom rejestru usługi ATA. Specyfikacja usługi ATA ACS może służyć do dekodowania poniższych wartości w przypadku niepowodzenia polecenia Pobierz mikrokod:

• Kod powrotu: 0 (0000 0000) (N/A — bez znaczenia, ponieważ nie przesłano ładunku).
• Funkcje: 15 (0000 1111) (Bit 1 ma wartość "1" i wskazuje "przerwanie").
• Liczba sektorów: 0 (0000 0000) (Nie dotyczy)
• DriveHead: 160 (1010 0000) (N/A — ustawiono tylko przestarzałe bity).
• Polecenie: 146 (1001 0010) (Bit 1 ma wartość "1" wskazującą dostępność danych sense).

Informuje nas to, że operacja aktualizacji oprogramowania układowego została przerwana przez urządzenie.

Podobny poziom informacji o debugowaniu jest dostępny w tym kanale w przypadku korzystania z urządzeń NVMe z natywnym sterownikiem NVMe systemu Windows (StorNVMe.sys).