Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED in veracrypt.sys 1.26.7 when booting unencrypted Windows system partition #1414

Open
kriegste opened this issue Sep 8, 2024 · 2 comments
Labels

Comments

@kriegste
Copy link

kriegste commented Sep 8, 2024

Last night I had to restore a backup of my Windows 11 installation.

The backup was made "online", ie. from within the running (encrypted) OS. This way, since VeraCrypt decrypts the data transparently, the resulting backup image contains the unencrypted contents of the Windows system partition.
This is ok and I do it this way since the days of TrueCrypt. With TrueCrypt restoring the backup (offline, using a bootable usb key) was not an issue. I could just hit ESC on the reboot and skip the TrueCrypt bootloader. Windows booted just fine and I only had to reencrypt the system partition.

With VeraCrypt, this does not work anymore. :( I went through hell. Upon reboot, a blue screen appeared: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED in veracrypt.sys. Somehow VeraCrypt expected an encrypted system and crashed when it was found unencrypted.

So this would be my request: Make it so that veracrypt.sys does not crash when it finds the system unencrypted.

Mounting the partition using my bootable usb key was no problem. All my data was there, but it is not possible to remove VeraCrypt this way.

After elongated trial and error I found a solution:
I reinstalled Windows from scratch, installed VeraCrypt and encrypted C:
Luckily, my backup tool also has a "restore online" feature which can restore C: upon next start. This way, VeraCrypt of course encrypts the data while writing. This partition finally booted. :)

@kriegste kriegste added the bug label Sep 8, 2024
@idrassi
Copy link
Member

idrassi commented Sep 8, 2024

Thank you for the report.
There is a difference in logic in the driver to handle this case between MBR boot and UEFI boot.
I suspect you are in UEFI boot mode, right?

I will try to reproduce to find the cause of the crash.

@kriegste
Copy link
Author

kriegste commented Sep 8, 2024

Yes, UEFI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants