# Locate the failed layer in a drive firmware-update attempt

> How should a failed Windows drive firmware update be investigated?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-029-locate-the-failed-layer-in-a-drive-firmware-update-attempt/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-08T18:16:42+00:00
- Modified: 2026-09-08T18:17:14+00:00
- Last reviewed by DSE: 2026-09-08
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

How should a failed Windows drive firmware update be investigated?

## Potentially affected

Use this review after a drive firmware operation fails or capability is uncertain.

## DSE recommendation

Reproduce the capability query without changing the firmware first.

## Article

## Source facts

Microsoft explains that the PowerShell firmware-update path depends on Windows storage APIs, drivers, hardware, and their implementation of the required commands. Failures can arise at several of these layers. The documentation uses Get-StorageFirmwareInfo with a PhysicalDisk object to check whether a device exposes the expected command support. For unsupported commands, Microsoft directs administrators to the vendor or Windows Server Catalog for suitable firmware or devices. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/troubleshoot-firmware-update).

## Applicability

Use this review after a drive firmware operation fails or capability is uncertain. Identify the exact drive, controller, driver, and attempted operation before retrying. Keep the original error and the device’s reported firmware version.

## DSE recommendation

Reproduce the capability query without changing the firmware first. Compare the returned information with the intended device and the vendor documentation. Escalate a command-support gap with the hardware details and original failure evidence. Ask the storage owner to approve any further update attempt, including its workload impact, instead of treating repeated retries as a diagnostic method.

## Verification

Retain the query output and identify the layer for which support remains unconfirmed. If a vendor-approved correction is later tested, compare the before-and-after capability and firmware observations. Check the associated workload through the agreed acceptance procedure. Close the issue only when the original failure and the corrective action are both accounted for.

## Official references

[Microsoft Learn: Troubleshooting drive firmware updates](https://learn.microsoft.com/en-us/windows-server/storage/troubleshoot-firmware-update). Source reviewed September 8, 2026.

## Primary reference

- Name: Troubleshooting drive firmware updates
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/windows-server/storage/troubleshoot-firmware-update
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Locate the failed layer in a drive firmware-update attempt,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-029-locate-the-failed-layer-in-a-drive-firmware-update-attempt/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.