Solução de problemas de atualizações de firmware de unidade

O Windows 10, versão 1703 e mais recentes incluem a capacidade de atualizar o firmware de HDDs e SSDs que foram certificados com o AQ (Qualificador Adicional) de upgrade de firmware por meio do PowerShell.

Você pode encontrar mais informações sobre esse recurso aqui:

• Atualizar o firmware da unidade no Windows Server 2016
• Atualizar o firmware de unidade sem tempo de inatividade em Espaços de Armazenamento Diretos

As atualizações de firmware podem falhar por vários motivos. O objetivo deste artigo é ajudar na solução de problemas avançada.

Observação

As informações contidas neste artigo, dependendo do problema, podem não ser suficientes para depurar todos os casos de falha possíveis.

Problemas comuns

Em termos de arquitetura, esse novo recurso depende de APIs implementadas na pilha de armazenamento do Windows, em que o PowerShell é chamado. A pilha de armazenamento depende de drivers e hardware para implementar comandos definidos pelo setor adequadamente. Isso resulta em vários pontos em que podem ocorrer falhas. Os problemas mais comumente observados são:

• Uma determinada unidade não implementa corretamente os comandos padrão do setor (não tem o AQ)
• As APIs necessárias para executar a atualização não são implementadas ou estão com defeito (se drivers de terceiros forem usados).
• As APIs funcionam, mas há um problema com o firmware em si (por exemplo, uma imagem inválida/corrompida).

As seções a seguir descrevem informações de solução de problemas, dependendo se drivers da Microsoft ou de terceiros são usados.

Identificando hardware inadequado

A maneira mais rápida para identificar se um dispositivo dá suporte ao conjunto correto de comandos é iniciar o PowerShell e passar um objeto do disco que representa PhysicalDisk para o cmdlet Get-StorageFirmwareInfo. Veja um exemplo:

Get-PhysicalDisk -SerialNumber 15140F55976D | Get-StorageFirmwareInformation

Veja também um exemplo de saída:

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

O campo SupportsUpdate, pelo menos para dispositivos SATA e NVMe, indica se a funcionalidade interna do PowerShell pode ser usada para atualizar o firmware.

O campo SupportsUpdate sempre relatará "True" para dispositivos conectados a SAS, pois não é possível consultar o suporte de comando apropriado com comandos padrão do setor.

Para validar se um dispositivo SAS aceita o conjunto de comandos necessários, existem duas opções:

• Testar o dispositivo SAS via cmdlet Update-StorageFirmware com uma imagem do firmware apropriada, ou
• Consulte o Windows Server Catalog para identificar quais dispositivos SAS obtiveram o AQ de atualização de firmware (https://www.windowsservercatalog.com/)

Opções de correção

Se um determinado dispositivo que você está testando não der suporte ao conjunto de comandos apropriado, consulte seu fornecedor para ver se um firmware atualizado que fornece o conjunto de comandos necessário está disponível ou consulte o catálogo do Windows Server para identificar dispositivos de origem que implementam o conjunto de comandos apropriado.

Solução de problemas com drivers de terceiros (SAS)

Os componentes de software que melhor interagem com hardware são drivers de miniporta na pilha de armazenamento do Windows. Para alguns protocolos de armazenamento, como SATA e NVMe, a Microsoft fornece drivers nativos do Windows. Esses drivers dão suporte a informações adicionais de depuração. No entanto, fornecedores de hardware e software de terceiros podem escrever drivers de miniporta personalizados para seus dispositivos. Nesses casos, o suporte para informações de depuração pode variar.

Para identificar o que aconteceu com o download de firmware e ativar as APIs enviadas para a pilha de armazenamento, independentemente do driver de miniporta, consulte o canal de log de eventos a seguir:

Visualizador de Eventos - Logs de aplicativos e serviços - Microsoft - Windows - StorDiag - Microsoft-Windows-Storage-ClassPnP/Operational

Esses canal registra as informações sobre as APIs do Windows enviadas para os drivers de miniporta e as respostas delas. Por exemplo, a seguinte condição de erro ocorre ao tentar fazer download de uma imagem de firmware para um dispositivo SATA conectado por meio de um HBA SAS que não implementa corretamente a conversão necessária de SAS em SATA:

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

Veja um exemplo da saída:

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

O PowerShell gera um erro e receberá informações indicando que a função chamada (ou seja, API de Kernel) estava incorreta. Um erro indicar que a API não foi implementada pelo driver de miniporta SAS de terceiros (correto nesse caso) ou que a API falhou por outro motivo, como um alinhamento incorreto de segmentos de download.

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

O evento 507 de ETW do canal mostra que uma solicitação de SCSI SRB falhou e fornece informações adicionais indicando que SenseKey foi '5' (solicitação ilegal), e que as informações AdditionalSense foram '36' (campo ilegal em CDB).

Observação

Essas informações são fornecidas diretamente pela miniporta em questão e a precisão dessas informações depende da implementação e da sofisticação do driver de miniporta.

É possível que condições de erro diferentes exibam os mesmos códigos de erro, se o driver de miniporta não as diferenciar. Por exemplo, tentar fazer download de uma imagem de firmware inválida por meio de um HBA SAS para um dispositivo SATA (que deve falhar) pode resultar em códigos de falha idênticos.

Em casos onde protocolos são misturados e podem ocorrer conversões, ou seja, SATA por trás de SAS, é melhor testar o dispositivo SATA diretamente conectado a um controlador de SATA para descartá-lo como um problema em potencial.

Opções de correção

Se o driver de terceiros for identificado como não implementando as APIs ou conversões necessárias, será possível usar as alternativas fornecidas pela Microsoft para SATA (StorAHCI.sys) e NVMe (StorNVMe.sys) ou entrar em contato com o fornecedor OEM ou HBA que forneceu o driver SAS e consultar se existe uma versão mais recente com o suporte correto.

Mais soluções de problemas com drivers da Microsoft (SATA/NVMe)

Quando os drivers nativos do Windows, como StorAHCI.sys ou StorNVMe.sys, são usados para dispositivos de armazenamento de energia, é possível obter informações adicionais sobre casos de falha possíveis durante operações de atualização de firmware.

Além do canal de ClassPnP operacional, StorAHCI e StorNVMe registram os códigos de retorno específicos do protocolo do dispositivo no seguinte canal ETW:

Visualizador de Eventos - Logs de aplicativos e serviços - Microsoft - Windows - StorDiag - Microsoft-Windows-Storage-StorPort/Diagnose

Os logs de diagnóstico não são mostrados por padrão e podem ser ativados/mostrados selecionando "Exibir" no Visualizador de Eventos e selecionando "Mostrar Logs Analíticos e de Depuração" no menu suspenso.

Para coletar essas entradas avançadas do log, habilite o log, reproduza a falha de atualização de firmware e salve o log de diagnóstico.

Veja um exemplo de uma atualização de firmware em uma falha de dispositivo SATA, pois a imagem a ser baixada era inválida (ID de evento: 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

O evento acima contém informações detalhadas de dispositivo nos valores de parâmetro 2 a 6. Aqui estamos olhando vários valores do registro ATA. A especificação ATA ACS pode ser usada para decodificar os valores abaixo pela falha de um comando Download Microcode:

• Código de retorno: 0 (0000 0000) (N/A – sem sentido, pois nenhuma carga foi transferida.)
• Recursos: 15 (0000 1111) (Bit 1 é definido como '1' e indica "cancelar".)
• SectorCount: 0 (0000 0000) (N/A)
• DriveHead: 160 (1010 0000) (N/A – apenas bits obsoletos são definidos.)
• Comando: 146 (1001 0010) (Bit 1 é definido como '1' indicando a disponibilidade dos dados detectados.)

Isso informa que a operação de atualização de firmware foi cancelada pelo dispositivo.

Um nível semelhante de informações de depuração está disponível neste canal ao usar dispositivos NVMe com o driver NVMe nativo do Windows (StorNVMe.sys).