VeraCrypt / Forums / Technical Topics: BSOD last night

Gabriel Nilam - 2025-09-11

Hi everyone,

I’ve been using VeraCrypt for years on Windows 10 with full disk encryption, without any problems. Since support for Windows 10 is ending soon, I recently did a clean install of Windows 11. I set up VeraCrypt again, but this time I encrypted just the system partition (because full disk encryption isn’t supported on Win 11), so aside from Windows’ hidden partitions, that’s the only visible partition I have.

Everything seemed fine the first few days (I've been on Win 11 about 5 days now), but last night I got a random crash: black screen and then the machine rebooted. I analyzed the dump file (.dmp) with WinDbg, and it traced the crash to veracrypt.sys.

Here are some details from the dump:

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) Bugcheck code: 0x1000007E (0xC0000005, 0xFFFFF800180E96B8, …) Faulting module: veracrypt.sys Exception code: 0xC0000005 (Access violation) Failure bucket ID: AV_veracrypt!unknown_function

Instruction at crash:

veracrypt+0x496b8: fffff800180e96b8 f6410a05 test byte ptr [rcx+0Ah],5 ds:002b:000000000000000a=??

So far it’s only happened once, but it’s worrying. I also have Kaspersky Antivirus installed — same as I did on Windows 10, and never had any issue before.

I don’t know if this is a VeraCrypt bug, or something with Windows 11, or maybe a conflict with antivirus… whatever it is, I wanted to reach out in case others have seen the same. Any thoughts, suggestions, or if devs are aware of this kind of crash, I’d really appreciate the input.

Thanks!

Last edit: Gabriel Nilam 2025-09-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Enigma2Illusion - 2025-09-11

You forgot to include the version of VeraCrypt you are using on your Win 11 PC.

Did you have your Win 11 setup to automatically apply Microsoft patches which require reboots?

Have you checked the Microsoft Event Viewer or Windows > Settings > Update & Security > View update history to see if Microsoft performed a patch on the day of the crash?

Last edit: Enigma2Illusion 2025-09-11

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gabriel Nilam - 2025-09-11

I'm using (and have been using) VeraCrypt version 1.26.24, the latest available version.

I checked Event Viewer, but didn’t see anything useful other than the usual message saying the system rebooted and that a dump file was written.

The last Windows 11 update (KB5065426, build 26100.6584) was installed automatically the day before the crash, and I don’t believe it directly caused the issue.

The crash just happened out of nowhere, with no obvious trigger.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2025-09-12

Thank you @gabrielnilam for the report.

I'm not aware of random BSOD like this.

Did you try to use VeraCrypt driver Debugging symbols in WinDbg to get better information about the location of the crash? This will be helpful since the shared output only shows access violation. Hopefully with the pdb file we can see approximate location of the crash and this may give us some hints.

Debugging symbols are available on the downloads page.

Access violation means that the driver is trying to access some invalid field or memory. There are a lot of defensive checks in the driver to protect against such issues so it must be something really unusual that bypasses the checks.

Did you enable any settings other than VeraCrypt defaults? (e.g. "Enable extended disk control codes support", "Activate encryption of keys and passwords stored in RAM")

Let's hope you can get more information using the debugging symbols.

👍
1

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gabriel Nilam - 2025-09-12

Luckily, the crash hasn’t happened again so far, and I’m hoping it was just a one-time thing.

I just finished analyzing the dump using the VeraCrypt driver debugging symbols. Here’s what I found:

veracrypt!MainThreadProc+0x508 EncryptedIoQueue.c @ line 875 MmGetSystemAddressForMdlSafe called with a null MDL (rcx = 0x0) Instruction: test byte ptr [rcx+0Ah], 5 Exception: 0xC0000005 (Access violation) Attempted read from address 0x000000000000000A Failure bucket ID: AV_veracrypt!MainThreadProc

As for the rest, I haven’t changed any default settings:
"Enable extended disk control codes support" and "Activate encryption of keys and passwords stored in RAM" are both unchecked.

❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2025-09-13

@gabrielnilam: Thank you for the sharing the dump analysis. This is an amazing finding: irp->MdlAddress passed to MmGetSystemAddressForMdlSafe in MainThreadProc is NULL! See https://sourceforge.net/p/veracrypt/code/ci/VeraCrypt_1.26.24/tree/src/Driver/EncryptedIoQueue.c#l875

This was not expected at all. After some research, it turned that this is completely legal on Windows although rare and it can happen in cases where a filter in the stack above us is using buffered I/O (maybe Kaspersky in your case).

I'm now implementing needed changes to properly handle this case and avoid such crash.

Thank you again for taking the time and effort to analyze the crash dump. Receiving such help is very rare and very much appreciated.

❤️
1

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- SelectLine - 2025-09-18
  
  @idrassi
  
  Hi, when do you plan to release the next beta version of VeraCrypt for Windows?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2025-09-18

@selectline
I already fixed the BSOD issue and I was working on SSD/NVMe drives speedup and the low memory freeze issue. All of them are related to the Windows driver and so I'm trying to include as much changes as possible in the beta.

I will decide today if I will include the SSD/NVMe changes or not. So you should expect a beta this Saturday.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- SelectLine - 2025-09-18
  
  Love You
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2025-09-20

Update: I have to do some changes on the UI to add new option for Secure Desktop and overhaul how preferences are presented (I'm using tab control).
For the driver, the SSD/NVMe changes are not stable and so they will not be published. I have submitted the new driver containing the BSOD fix and other enhancements to Microsoft for signing.
It is getting late here so I will resume tomorrow morning to create the installers once the signed driver is received.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- SelectLine - 2025-09-20
  
  @idrassi
  
  Thank you very much :) Will the new beta version have Argon2 implemented for UEFI?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- SelectLine - 2025-09-20
  
  @idrassi
  
  Will the new beta version be compatible with VeraCrypt x64 version 1.26.26 (container encryption Argon2)?
  
  Last edit: SelectLine 2025-09-20
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- SelectLine - 2025-09-21
  
  ?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2025-09-21

@selectline I have uploaded version 1.26.27 with latest changes. It is compatible with 1.26.26 for Argon2.
UEFI support is not yet done. It will require moving to 1.27.x.
I have been spending time on the driver, so UEFI is in standby. Unfortunately, SSD speedup proved to be very challenging on robustness side so this effort didn't lead yet to a publishable result.
I will put the drive aside and look into UEFI bootloader to bring Argon2.

❤️
1

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- SelectLine - 2025-09-21
  
  Thank you! I'm going to test it now. <3
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Niles Patchernek - 2025-09-21
  
  Hi @idrassi,
  
  thank you very much for your work and release.
  
  I apologize for hijacking this thread, but might the following issues be resolved with the UEFI update?
  
  Veracrypt on Hyper-V?
  VeraCrypt and Windows 11 24H2 stuck during "booting..."
  System encryption pretest fails on win10
  Precise error information for pretest failure
  
  Thank you
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Mounir IDRASSI - 2025-09-22
  
  @nilchernek: the 4 issues you mentionned fall in two categories:
  
  pretest failure: this is most likely causes by the fact that the driver fails to locate the bootloader boot arguments necessary for the encryption. These boot arguments are stored in special memory regions that normally allow communication between the bootloader and the driver.
  
  It happens that on some machines the memory range used by VeraCrypt bootloader is overwritten by another driver on the machine because VeraCrypt driver could read it.
  We cannot really declare that a memory range is ours and so there is big risk.
  
  Currently, EIF bootloader writes into a single memory range. One possible solution is to write to several memory ranges to reduce the probability of overwrite by other driver that start before us.
  
  I'm not sure about the risks associated with this approach but it is worth trying.
  
  boot stuck: this is more difficult to diagnose. VeraCrypt bootloader starts Windows bootloader and in affected machine Windows bootloader never starts. It seems to be related to a recent change on Windows side. VeraCrypt overwrite Windows bootloader in order to support some configurations (like HP machines) where the BIOS forces the boot on Windows bootloader.
  
  One idea would be to give advanced control to user over whether the Windows bootloader is overwritten or not, knowing the disable it may cause boot issues on some BIOSes (which can be solved using VeraCrypt Rescue Disk if they happen).
  
  I will investigate these approaches.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Niles Patchernek - 2025-09-22
    
    Thank you very much for your detailed answer.
    
    If I can assist / test something please let me know.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

SelectLine - 2025-09-22

@idrassi

Hello again, I tested the latest beta version 1.26.27 and didn't find any errors on my hardware. I’m waiting for support for UEFI encryption because it's a priority for me (Argon2)

Thank you, bro!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

BSOD last night — crash in veracrypt.sys

Open source disk encryption with strong security for the Paranoid

Forums

Help

BSOD last night — crash in veracrypt.sys

BSOD last night — crash in veracrypt.sys

Open source disk encryption with strong security for the Paranoid

Forums

Help

BSOD last night — crash in veracrypt.sys document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

BSOD last night — crash in veracrypt.sys