BSOD 0xA (IRQL_NOT_LESS_OR_EQUAL): veracrypt.sys causes NULL Irp->UserEvent dereference in KeSetEvent during volume mount

[milan964]

In 4 of 5 dumps PROCESS_NAME is VeraCrypt.exe, with veracrypt+0x4e8cc as the direct caller of NtCreateFile. In the 5th dump, PROCESS_NAME is System, with the call coming from mountmgr!ReconcileThisDatabaseWithMasterWorker → mountmgr!OpenRemoteDatabase — Mount Manager reacting to the same volume-arrival event from a different thread.

WinDbg also reports *** WARNING: Unable to verify timestamp for veracrypt.sys in 4 of 5 dumps.

Suspected root cause: Irp->UserEvent is dereferenced at completion time while pointing to invalid/freed memory. This is consistent with a synchronous I/O request issued by veracrypt.sys using a short-lived (likely stack-allocated) KEVENT combined with a finite wait timeout: if the underlying storage stack does not complete the IRP before the timeout expires, veracrypt.sys's wait returns and the event's storage may be reused/invalidated — but without the IRP being cancelled. When the storage stack later does complete that IRP, IopCompleteRequest dereferences the now-invalid UserEvent pointer, causing the crash at DISPATCH_LEVEL (since storage completion typically happens via DPC).

All captured crashes show concurrent FLTMGR!FltpDoFilterNotificationForNewVolume activity (Windows attaching registered minifilters — in our case including a third-party disk-encryption filesystem filter — to the newly-arrived VeraCrypt volume). We believe this is not the root cause itself, but widens the race window described above (more registered minifilters → longer FltpInitInstance → higher chance the storage stack responds after veracrypt.sys's wait has already timed out).

Note: I noticed that 1.26.29 release notes mention "Improve driver I/O handling, including safer request completion" and "Fix rare BSOD issue affecting the VeraCrypt driver" — this may already address this issue. I am upgrading to test and will update this report with the result.

Steps to reproduce

1. Install VeraCrypt 1.26.24 on a system that also has another disk-encryption
   product's filesystem filter driver installed (in our case: Symantec/Broadcom
   Encryption Desktop — PGPfsfd.sys, PGPwded.sys, Pgpwdefs.sys), on top of an
   Intel VROC RAID storage stack (iaVROC.sys/mpi3drv.sys under storport.sys).
2. Use the system normally, mounting/dismounting VeraCrypt volumes as usual.
3. No single specific action reliably triggers the crash — it occurred 5 times
   over approximately 2 days of normal use, always within seconds of volume
   mount/dismount activity (confirmed via PROCESS_NAME and stack trace in all
   5 dumps), not on every single mount.
4. System bugchecks with IRQL_NOT_LESS_OR_EQUAL (0xA), consistently in
   nt!KeSetEvent as described above.

We do not have a 100%-reliable single-step repro; this report is based on
5 independent crash dumps with identical signatures collected from the same
machine. We suspect the trigger is timing-dependent (a race between the
storage stack completing an I/O request and a synchronous wait timeout in
veracrypt.sys — see root cause analysis above), which would explain why it
doesn't reproduce on every mount.

Screenshots

N/A

122025-31640-01.dmp
122025-32406-01.dmp
122125-32281-01.dmp
122125-32640-01.dmp
122225-32531-01.dmp

Your Environment

Please tell us more about your environment
VeraCrypt version: 1.26.24 (driver timestamp: Thu May 29 09:43:28 2025)
Operating system and version: Windows 11, build 10.0.26100.7462 (24H2)
System type: 64-bit (x64), 24 logical processors, Hyper-V-enlightened guest