I experienced two related storage-instability patterns involving VeraCrypt and Bitdefender.
First, after enabling VeraCrypt system encryption on the Windows system drive, the computer repeatedly crashed during boot or restart with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E) BSODs naming veracrypt.sys. A separate PAGE_FAULT_IN_NONPAGED_AREA (0x50) crash occurred in the Windows Filter Manager / NTFS I/O path while Bitdefender and VeraCrypt were both active.
Later, after permanently decrypting the Windows system drive, I reproduced a serious kernel storage hang while Bitdefender was active and a sustained file transfer was running between two external VeraCrypt volumes. The affected VeraCrypt-mounted exFAT volume became inaccessible, VeraCrypt stopped responding, Bitdefender Virus Shield terminated, and Windows could not restart normally.
The live-kernel dump showed that a bdservicehost.exe thread owned the blocked exFAT resource while waiting for a pending write whose current driver was \Driver\veracrypt and whose target device was VeraCryptVolumeY.
I am reporting this as a possible compatibility or interaction issue involving VeraCrypt, Bitdefender filesystem filtering, exFAT, and sustained USB storage I/O. I am not asserting that VeraCrypt alone or Bitdefender alone is conclusively the sole cause.
Expected behavior
Two mounted VeraCrypt volumes on external USB drives should remain accessible and a sustained file transfer between them should complete normally.
VeraCrypt should remain responsive, Windows Explorer should remain responsive, and Windows should be able to shut down or restart normally.
Observed behavior
During a sustained file transfer between two external USB drives containing VeraCrypt volumes, the mounted VeraCrypt volume Y: became inaccessible while the physical USB drive still appeared present in Windows.
At the same time:
VeraCrypt became unresponsive.
Windows Explorer became affected by the inaccessible volume.
Bitdefender Antivirus / Virus Shield stopped responding and Windows Security reported that antivirus protection needed attention.
Bitdefender’s Virus Shield service later logged as having terminated unexpectedly.
Bitdefender file-system filters unloaded and reloaded.
Windows generated a ResourceTimeout live-kernel dump.
Normal Windows restart remained stuck on the spinning-dots screen and eventually required a forced shutdown.
There was no normal BSOD during this particular incident.
WinDbg analysis of the ResourceTimeout live dump showed:
EXRESOURCE_TIMEOUT_LIVEDUMP (0x1CC)
The timed-out exFAT resource was owned by a thread in bdservicehost.exe.
That Bitdefender-owned thread was waiting in an exFAT write/flush path.
Its active write IRP was IRP_MJ_WRITE.
The current driver for that write IRP was \Driver\veracrypt.
The target device object was identified as:
VeraCryptVolumeY \Driver\veracrypt
An explorer.exe thread was blocked waiting to acquire the same exFAT resource.
Relevant WinDbg excerpt:
IRP_MJ_WRITE
\Driver\veracrypt
exfat!FppSingleSyncCompletionRoutine
Device object:
VeraCryptVolumeY \Driver\veracrypt
I am not asserting that VeraCrypt alone caused this. The available live dump does not show enough of the lower USB/storage stack to determine whether the initiating problem was VeraCrypt, Bitdefender, their interaction, exFAT, USB storage, the enclosure/cable, or another lower storage component.
However, VeraCryptVolumeY was directly identified in the pending write path during the kernel resource timeout.
Additional context: earlier on this same laptop, after VeraCrypt system encryption was enabled on the Windows system drive, I experienced repeated SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E) BSODs naming veracrypt.sys during boot/restart. I also experienced a separate PAGE_FAULT_IN_NONPAGED_AREA (0x50) event involving Filter Manager while Bitdefender was active. I have since permanently decrypted the Windows system drive.
Earlier VeraCrypt system-encryption BSOD history
Before the external-volume ResourceTimeout incident, I had enabled VeraCrypt system encryption on the Windows system drive on this same laptop.
After system encryption was completed, I experienced repeated boot and restart BSODs, including multiple:
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E)
events that identified:
veracrypt.sys
as the named driver.
These failures occurred during normal restart or boot activity, including cases where Windows could not start normally after the VeraCrypt pre-boot authentication stage. At least one crash did not produce a usable dump, but the repeated BSOD screen reports consistently named veracrypt.sys.
A separate kernel-memory dump from this period recorded:
PAGE_FAULT_IN_NONPAGED_AREA (0x50)
The active process was bdservicehost.exe, and the stack was in the Windows Filter Manager / NTFS I/O path, including:
FLTMGR!FltpPerformPreCallbacksWorker
At the time of that crash, VeraCrypt was loaded and Bitdefender's filesystem-filter stack was active, including vlflt, BdDci4, Ignisv2, Gemma, atc, and Trufos.
The crash stack did not directly show a Bitdefender driver function or veracrypt.sys executing at the faulting instruction. Therefore, I cannot conclude from that crash alone that either product was the sole cause. However, the event occurred in a heavily filtered filesystem I/O environment with both products active.
After I permanently decrypted the Windows system drive, I completed several normal restarts without a BSOD. This suggested that VeraCrypt system encryption was an important part of the earlier failure pattern, but it did not prove that normal VeraCrypt mounted volumes were stable.
The later ResourceTimeout incident then occurred with the Windows system drive decrypted, while Bitdefender was active and ordinary external VeraCrypt volumes were being used under sustained I/O. This indicates that the instability is not limited only to VeraCrypt system encryption and may involve an interaction between Bitdefender, VeraCrypt, the filesystem-filter stack, and external USB/exFAT storage.
Steps to reproduce
Start Windows normally with Bitdefender Antivirus installed and active.
Connect two external USB drives containing VeraCrypt-encrypted volumes.
Mount both VeraCrypt volumes. In the incident, the affected mounted volume was Y: and used exFAT.
Start a sustained large file transfer between the two mounted VeraCrypt volumes.
Leave the transfer running.
Observed result in my case: after the transfer had been running, the Y: mounted VeraCrypt volume became inaccessible, VeraCrypt stopped responding, Bitdefender Virus Shield failed, Windows created a ResourceTimeout live dump, and Windows could not restart normally.
I understand this may not reproduce on every attempt or every computer. The issue occurred on the hardware and software environment listed below.
Screenshots
Your Environment
VeraCrypt version: 1.26.29
Operating system and version: Windows 11 Home, version 25H2, OS build 26200.837
System type: 64-bit operating system, x64-based processor
Laptop: ASUS ROG Strix G16 G615LW
BIOS version: G615LW.336
CPU: Intel Core Ultra 9 290HX Plus
Memory: 64 GB DDR5, 5600 MT/s
Bitdefender: 27.0.60.339
GPU: NVIDIA GeForce RTX 5080 Laptop GPU
Drive configuration: Windows system drive was decrypted at the time of this incident. VeraCrypt system encryption was not active. Two external USB drives containing VeraCrypt volumes were mounted.
Filesystem involved: exFAT on the affected VeraCrypt-mounted volume.
I experienced two related storage-instability patterns involving VeraCrypt and Bitdefender.
First, after enabling VeraCrypt system encryption on the Windows system drive, the computer repeatedly crashed during boot or restart with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E) BSODs naming veracrypt.sys. A separate PAGE_FAULT_IN_NONPAGED_AREA (0x50) crash occurred in the Windows Filter Manager / NTFS I/O path while Bitdefender and VeraCrypt were both active.
Later, after permanently decrypting the Windows system drive, I reproduced a serious kernel storage hang while Bitdefender was active and a sustained file transfer was running between two external VeraCrypt volumes. The affected VeraCrypt-mounted exFAT volume became inaccessible, VeraCrypt stopped responding, Bitdefender Virus Shield terminated, and Windows could not restart normally.
The live-kernel dump showed that a bdservicehost.exe thread owned the blocked exFAT resource while waiting for a pending write whose current driver was \Driver\veracrypt and whose target device was VeraCryptVolumeY.
I am reporting this as a possible compatibility or interaction issue involving VeraCrypt, Bitdefender filesystem filtering, exFAT, and sustained USB storage I/O. I am not asserting that VeraCrypt alone or Bitdefender alone is conclusively the sole cause.
Expected behavior
Two mounted VeraCrypt volumes on external USB drives should remain accessible and a sustained file transfer between them should complete normally.
VeraCrypt should remain responsive, Windows Explorer should remain responsive, and Windows should be able to shut down or restart normally.
Observed behavior
During a sustained file transfer between two external USB drives containing VeraCrypt volumes, the mounted VeraCrypt volume Y: became inaccessible while the physical USB drive still appeared present in Windows.
At the same time:
VeraCrypt became unresponsive.
Windows Explorer became affected by the inaccessible volume.
Bitdefender Antivirus / Virus Shield stopped responding and Windows Security reported that antivirus protection needed attention.
Bitdefender’s Virus Shield service later logged as having terminated unexpectedly.
Bitdefender file-system filters unloaded and reloaded.
Windows generated a ResourceTimeout live-kernel dump.
Normal Windows restart remained stuck on the spinning-dots screen and eventually required a forced shutdown.
There was no normal BSOD during this particular incident.
WinDbg analysis of the ResourceTimeout live dump showed:
EXRESOURCE_TIMEOUT_LIVEDUMP (0x1CC)
The timed-out exFAT resource was owned by a thread in bdservicehost.exe.
That Bitdefender-owned thread was waiting in an exFAT write/flush path.
Its active write IRP was IRP_MJ_WRITE.
The current driver for that write IRP was \Driver\veracrypt.
The target device object was identified as:
VeraCryptVolumeY \Driver\veracrypt
An explorer.exe thread was blocked waiting to acquire the same exFAT resource.
Relevant WinDbg excerpt:
IRP_MJ_WRITE
\Driver\veracrypt
exfat!FppSingleSyncCompletionRoutine
Device object:
VeraCryptVolumeY \Driver\veracrypt
I am not asserting that VeraCrypt alone caused this. The available live dump does not show enough of the lower USB/storage stack to determine whether the initiating problem was VeraCrypt, Bitdefender, their interaction, exFAT, USB storage, the enclosure/cable, or another lower storage component.
However, VeraCryptVolumeY was directly identified in the pending write path during the kernel resource timeout.
Additional context: earlier on this same laptop, after VeraCrypt system encryption was enabled on the Windows system drive, I experienced repeated SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E) BSODs naming veracrypt.sys during boot/restart. I also experienced a separate PAGE_FAULT_IN_NONPAGED_AREA (0x50) event involving Filter Manager while Bitdefender was active. I have since permanently decrypted the Windows system drive.
Earlier VeraCrypt system-encryption BSOD history
Before the external-volume ResourceTimeout incident, I had enabled VeraCrypt system encryption on the Windows system drive on this same laptop.
After system encryption was completed, I experienced repeated boot and restart BSODs, including multiple:
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E)
events that identified:
veracrypt.sys
as the named driver.
These failures occurred during normal restart or boot activity, including cases where Windows could not start normally after the VeraCrypt pre-boot authentication stage. At least one crash did not produce a usable dump, but the repeated BSOD screen reports consistently named veracrypt.sys.
A separate kernel-memory dump from this period recorded:
PAGE_FAULT_IN_NONPAGED_AREA (0x50)
The active process was bdservicehost.exe, and the stack was in the Windows Filter Manager / NTFS I/O path, including:
FLTMGR!FltpPerformPreCallbacksWorker
At the time of that crash, VeraCrypt was loaded and Bitdefender's filesystem-filter stack was active, including vlflt, BdDci4, Ignisv2, Gemma, atc, and Trufos.
The crash stack did not directly show a Bitdefender driver function or veracrypt.sys executing at the faulting instruction. Therefore, I cannot conclude from that crash alone that either product was the sole cause. However, the event occurred in a heavily filtered filesystem I/O environment with both products active.
After I permanently decrypted the Windows system drive, I completed several normal restarts without a BSOD. This suggested that VeraCrypt system encryption was an important part of the earlier failure pattern, but it did not prove that normal VeraCrypt mounted volumes were stable.
The later ResourceTimeout incident then occurred with the Windows system drive decrypted, while Bitdefender was active and ordinary external VeraCrypt volumes were being used under sustained I/O. This indicates that the instability is not limited only to VeraCrypt system encryption and may involve an interaction between Bitdefender, VeraCrypt, the filesystem-filter stack, and external USB/exFAT storage.
Steps to reproduce
Start Windows normally with Bitdefender Antivirus installed and active.
Connect two external USB drives containing VeraCrypt-encrypted volumes.
Mount both VeraCrypt volumes. In the incident, the affected mounted volume was Y: and used exFAT.
Start a sustained large file transfer between the two mounted VeraCrypt volumes.
Leave the transfer running.
Observed result in my case: after the transfer had been running, the Y: mounted VeraCrypt volume became inaccessible, VeraCrypt stopped responding, Bitdefender Virus Shield failed, Windows created a ResourceTimeout live dump, and Windows could not restart normally.
I understand this may not reproduce on every attempt or every computer. The issue occurred on the hardware and software environment listed below.
Screenshots
Your Environment
VeraCrypt version: 1.26.29
Operating system and version: Windows 11 Home, version 25H2, OS build 26200.837
System type: 64-bit operating system, x64-based processor
Laptop: ASUS ROG Strix G16 G615LW
BIOS version: G615LW.336
CPU: Intel Core Ultra 9 290HX Plus
Memory: 64 GB DDR5, 5600 MT/s
Bitdefender: 27.0.60.339
GPU: NVIDIA GeForce RTX 5080 Laptop GPU
Drive configuration: Windows system drive was decrypted at the time of this incident. VeraCrypt system encryption was not active. Two external USB drives containing VeraCrypt volumes were mounted.
Filesystem involved: exFAT on the affected VeraCrypt-mounted volume.