How to reset live Storage QoS tracking table?

Question

An online expansion of a 4TB VHDX under Storage QoS crashed storqosflt.sys and all VM I/O on our Cluster Shared Volume is now hanging indefinitely. How do we patch or reset the live Storage QoS tracking table to recover from this?

Answer 1

Welcome to Microsoft Q&A!

Thank you for providing the detailed information.

There is no supported method to directly patch, clear, or reset the live Storage QoS tracking table maintained by storqosflt.sys. The Storage QoS state is held in kernel memory by the Storage QoS filter driver and does not expose any PowerShell cmdlets, registry settings, or public APIs to repair, rebuild, or refresh the in-memory tracking table if it becomes corrupted.

When storqosflt.sys crashes or enters a hung state causing VM I/O on a Cluster Shared Volume (CSV) to remain indefinitely queued, the situation should be treated as a filter driver failure rather than a recoverable Storage QoS policy issue.

I would like to recommend the following actions:

1. Collect diagnostic data

Generate cluster logs: Get-ClusterLog -UseLocalTime

Review the following data sources:

• System event logs
• Microsoft-Windows-StorageQoS events
• Hyper-V-StorageVSP events
• Failover Clustering events
• Any crash dumps or bugchecks referencing storqosflt.sys

It is a recommendation collecting cluster logs and event logs as part of troubleshooting storage and cluster-related failures.  

2. Check the state of the CSV

Verify whether the CSV has entered a paused or redirected state. Look for:

• Event ID 5120
• Event ID 5142
• Storage timeout events
• Queued I/O conditions

Please note that a disruption in CSV connectivity can cause I/O requests to remain queued until the cluster regains access to the volume. This behavior is commonly observed during events such as CSV Event IDs 5120 and 5142.

3. Fail over workloads or reboot the affected node(s)

Because the Storage QoS tracking state is maintained in memory, the supported recovery method is to reload the driver stack, which typically requires:

• Failing over workloads to another cluster node
• Rebooting the affected node

At this moment, there is no documented procedure to rebuild only the Storage QoS tracking table while the system remains online.

4. Apply the latest Windows Server updates

If the issue occurred during an online VHDX expansion operation, ensure that all cluster nodes are running the latest cumulative updates before attempting the operation again.

5. Engage Microsoft Support if the issue can be reproduced

A crash in storqosflt.sys during an online VHDX expansion is not expected behavior and may indicate a product defect. If the issue is reproducible, I recommend you opening a Microsoft Support case for further investigation and root cause analysis.
Reference: Storage Quality of Service | Microsoft Learn
Set storage QoS for clusters | Microsoft Learn
Troubleshoot Storage Issues in Hyper-V and Windows Server Failover Clusters - Windows Server | Microsoft Learn

If you find this answer helpful, please click Accept Answer.

Thank you for using Microsoft Q&A!