Windows Server 2025 storage performance issue

Question

We would like Microsoft to confirm: (1) whether storport.sys's DPC/interrupt completion-redirection logic changed between Windows Server 2022 and Windows Server 2025; (2) whether this is expected/by-design, e.g. related to the new Storage Multi-Queue (StorMQ) architecture; (3) whether a supported tuning option exists to reduce this overhead for virtualized, single-queue storage controllers such as VirtIO-SCSI.

Titel:

Storport.sys DPC completion-redirection increases kernel CPU per I/O ~1.7–1.9x on Windows Server 2025 vs. Windows Server 2022 (identical storage driver) — confirmed via ETW/WPR trace, persists after KB5099536

 

Description:

We are seeing a consistent storage performance regression on Windows Server 2025 compared to Windows Server 2022, running on otherwise identical virtualized hardware (same host, same VirtIO-SCSI storage controller and driver version — vioscsi.sys 100.103.104.30000, confirmed identical on both systems).

Symptom: sequential-write throughput is lower on Windows Server 2025 (baseline ≈5,477–6,013 MiB/s vs. ≈6,213–6,453 MiB/s on Windows Server 2022), and kernel CPU usage per I/O operation is 1.4x–3.3x higher, depending on workload.

We ruled out Virtualization-Based Security (VBS) state and storage driver version via controlled A/B testing (see attached report, Section 3). We then captured paired ETW (Microsoft-Windows-StorPort provider) and WPR (CPU + DPC/ISR call-stack) traces across an identical diskspd workload on both operating systems and analyzed them in Windows Performance Analyzer.

Finding: the VirtIO miniport driver (vioscsi.sys) contributes negligible, near-identical CPU cost on both OS versions (0.03% vs. 0.04% of total system CPU). The additional cost is concentrated in the built-in storage port driver's DPC completion-redirection routine, storport.sys!RaidpAdapterRedirectDpcRoutine, which consumes 1.70x more CPU on Windows Server 2025 than on Windows Server 2022 under an identical workload (full data in attached report, Section 5).

We re-tested after installing the July 2026 cumulative update (KB5099536, storport.sys build 26100.33158) — the regression persists and, by our measurement, has slightly widened rather than improved (Section 5.3).

Full methodology, data tables, and root-cause analysis are in the attached document. Six ETW/WPR trace files (.etl) are attached for direct inspection: two from Windows Server 2025 (before/after KB5099536), two from Windows Server 2022, all captured with matching workload and time windows.

Answer 1

Hello Saiqa, thank you for the detailed methodology and the paired ETW/WPR evidence. I could not find any public Microsoft documentation confirming that storport.sys completion-redirection behavior changed between Windows Server 2022 and Windows Server 2025, that the measured increase in storport.sys!RaidpAdapterRedirectDpcRoutine is an expected StorMQ design effect, or that KB5099536 addresses this scenario; the KB only documents general security and quality improvements for build 26100.33158.  Microsoft documents Storport DPC redirection and concurrent-channel capabilities as miniport performance options, but no supported administrator setting is published to disable or retune the internal redirection routine for a single-queue VirtIO-SCSI controller.

Given that the same miniport version and workload show materially different kernel CPU cost, and the regression persists after the latest cumulative update, this requires Windows storage engineering analysis rather than further generic OS tuning. Please open a Microsoft Unified or Premier Support request and provide the six ETL traces, the report, msinfo32, fltmc, Get-CimInstance Win32_PnPSignedDriver, and complete HKLM\SYSTEM\CurrentControlSet\Enum<VirtIO-SCSI instance>\Device Parameters data so the support team can validate interrupt mode, message count, queue negotiation, NUMA placement, and Storport performance flags. Avoid undocumented registry changes or manually altering interrupt/DPC affinity in production, as no supported workaround can currently be confirmed for this exact behavior.