Hi David,
I have a well documented performance regression of DiskCryptor volumes on Windows 11 25H2. I spent a day isolating it layer by layer on one machine and I think the dataset is clean enough to be useful. As far as I can tell (searched the github issues, this forum and the web) nobody has documented this yet, so posting it here. Happy to provide traces or run more tests.
Environment
Numbers (CrystalDiskMark 8.0.6, default profile 512MiB, RND4K Q32T1, MB/s read / write)
A few things stand out:
Per-IO cost (RND4K QD32, microseconds per command)
So DC's own per-command surcharge roughly **tripled** with the OS upgrade. The workload is CPU bound (DiskSpd shows one P-core 97% kernel saturated at 178K IOPS raw), so per-IO overhead cuts IOPS linearly. QD1 tells the same story: +16 us (24H2) -> +29-38 us (25H2) per round trip.
What I eliminated (each verified, not assumed)
Possibly related context
25H2s storage/crypto internals are visibly in motion: the new opt-in Microsoft NVMe driver breaks VeraCrypt FDE boot (their #1640), VeraCrypt is collecting 25H2 read/write error reports (#617), and Microsoft moved BitLocker toward hardware acceleration in 25H2 citing software encryption overhead. My data says the base stack itself only moved slightly, but something in how 25H2 services a volume-filter encryption drivers IO path got ~3x more expensive per request.
Questions
1. Is this known? Are there measurements of dcrypts per-request path on 26200 vs 26100?
2. Anything in how dcrypt attaches / processes IRPs (completion routine depth, stack locations, allocation paths, in-place processing) that 25H2s storage/FltMgr changes would penalize? It looks like a per-IRP fixed cost increase that needs dcrypt in the path but no particular volume type
3. Any tuning available or planned (request coalescing / queueing)? Would a WPR/xperf CPU sampling trace of the 4K workload help? Happy to capture one on 25H2 (I dont have a 24H2 machine anymore, but the fresh partition control brackets the OS side)
Thanks for DiskCryptor and the 2.0 work
I have a well documented performance regression of DiskCryptor volumes on Windows 11 25H2. I spent a day isolating it layer by layer on one machine and I think the dataset is clean enough to be useful. As far as I can tell (searched the github issues, this forum and the web) nobody has documented this yet, so posting it here. Happy to provide traces or run more tests.
Environment
- ASUS ROG Strix SCAR 16 G635LX, Core Ultra 9 275HX (8P+16E), Windows 11 Pro 25H2 build 26200.8894 (upgraded from 24H2 on 2026-05-15)
- C: = Samsung 9100 PRO 4TB (PCIe 5.0), NTFS, DiskCryptor system encryption (AES-XTS) since July 2025
- DiskCryptor 2.0.1 now. The regression was first measured while still on the old 1.x driver (dcrypt.sys built 2024-02-15) and is identical on 2.0.1
Numbers (CrystalDiskMark 8.0.6, default profile 512MiB, RND4K Q32T1, MB/s read / write)
A few things stand out:
- the unencrypted 25H2 partition matches my 2025 native baseline *exactly* at RND4K Q1T1 (95.3 vs 93-96) and SEQ1M Q1T1 (9236/9637 vs ~9200/9600), so the OS storage stack by itself is nearly innocent
- a freshly created 2.0.1 volume pays the same tax as my 2025-era in-place converted system volume (121.6 vs ~100-112). So its not the header format, volume vintage or the boot chain
- SEQ1M Q8T1 is unaffected (~12-14 GB/s everywhere). DCs single-stream SEQ1M Q1T1 cost got worse too (4.5-4.9 GB/s on 24H2 -> 3.4-4.7 on 25H2, reads worst)
Per-IO cost (RND4K QD32, microseconds per command)
So DC's own per-command surcharge roughly **tripled** with the OS upgrade. The workload is CPU bound (DiskSpd shows one P-core 97% kernel saturated at 178K IOPS raw), so per-IO overhead cuts IOPS linearly. QD1 tells the same story: +16 us (24H2) -> +29-38 us (25H2) per round trip.
What I eliminated (each verified, not assumed)
- the SSD: raw 4K QD32 on \\.\PhysicalDrive = 695 MB/s / 178K IOPS, full native speed. SMART clean
- DC version: FilterManager events prove the first slow runs executed on the old 2024-02-15 build, and 2.0.1 measures the same. Cipher benchmark: AES-XTS 35.3 GB/s, so crypto throughput is never the ceiling
- volume header / in-place conversion / bootloader: a fresh 2.0.1 data volume on a fresh partition pays the same tax. Also reproduced on a non-system data volume on a second drive over USB (SK hynix PC801 in a 10Gbps enclosure): DC adds +17-29 us per 4K command there as well, and the boot chain plays no role for that one
- antivirus + Sandboxie-Plus: disabling both recovers only ~10-15%
- all third party minifilters: Safe Mode (dcrypt + bare OS) measures the same ~95-100
- VBS: HVCI and kernel shadow stacks both verified OFF (SecurityServicesRunning = {0}), still ~107/116
- the base 25H2 storage stack alone: see the fresh partition row, only ~+3 us/IO and QD1 latency unchanged. The collapse needs dcrypt in the path
Possibly related context
25H2s storage/crypto internals are visibly in motion: the new opt-in Microsoft NVMe driver breaks VeraCrypt FDE boot (their #1640), VeraCrypt is collecting 25H2 read/write error reports (#617), and Microsoft moved BitLocker toward hardware acceleration in 25H2 citing software encryption overhead. My data says the base stack itself only moved slightly, but something in how 25H2 services a volume-filter encryption drivers IO path got ~3x more expensive per request.
Questions
1. Is this known? Are there measurements of dcrypts per-request path on 26200 vs 26100?
2. Anything in how dcrypt attaches / processes IRPs (completion routine depth, stack locations, allocation paths, in-place processing) that 25H2s storage/FltMgr changes would penalize? It looks like a per-IRP fixed cost increase that needs dcrypt in the path but no particular volume type
3. Any tuning available or planned (request coalescing / queueing)? Would a WPR/xperf CPU sampling trace of the 4K workload help? Happy to capture one on 25H2 (I dont have a 24H2 machine anymore, but the fresh partition control brackets the OS side)
Thanks for DiskCryptor and the 2.0 work