This project has moved and is read-only. For the latest updates, please go here.

BSOD when inserting encrypted media



I have found that VC will cause a BSOD under the following conditions using the December version and the latest version. (I was not using VC before that)

First the basics
Windows 7 PRO 64
8 Gig Ram
MSI Motherboard with Z77 chipset
Using embedded Intel disk controller
No arrays are configured
Disk HOT PLUG=true
My PC has drive dock connected via SATA II interface

Machine is up and running on a Veracrypt Fully encrypted system drive. SHA256/AES
Hot plug a drive encrypted with LUKS or DiskCryptor and VC blue screens. These can only be used if they are plugged in before I boot the computer and then I can interact with them

Hot plug a VC encrypted drive before Intel Rapid Storage utility has completed loading. I can either wait a few minutes for RST to be fully loaded (the ICON shows check mark) or boot with VC drive already in dock

In both cases the BSOD shows the VCcrypt.sys (or something very similar).. No mini dumps are written to the disk as the disk appears not writable once the VCrypt.sys driver has crashed.



file attachments


idrassi wrote Apr 28, 2015 at 9:55 PM


Thank you for the detailed report. This kind of issues is difficult to investigate as kernel debugging on the physical machine is required to determine what is causing the crash.

Do you have BSOD when you hotplug unencrypted drives?

I currently don't have access to similar hardware to debug locally so another way must be found to enable generating some kind of report that can be analyzed.

If I provide modified versions of VeraCrypt, is it possible for you to conduct tests on a test machine?

scottX wrote Apr 29, 2015 at 12:23 AM

I am willing to help test and run debug versions. I checked that my PC is configured to write mini-dumps, but none get created as I suspect the disk is inaccessible once the VCrypt.sys has crashed.

I should have clarified that the LUKS and Discrypter disks I hot plugged were only inserted as I was wiping them and encrypting with VC. So I have NO other encryption software or drivers on this PC. Of course I turn them into VC disks.

The first test that I can do is completely uninstall Intel Rapid Storage Driver and repeat my tests.

I will let you know the outcome shortly.

scottX wrote Apr 29, 2015 at 3:08 AM

As I was testing the scenarios to get them fully understood I did notice that on one insert of a LUKS disks I saw a dialog from Veracrypt saying something like.

_Veracrypt encountered a problem with the system, but the problem was not caused by Veracrypt and the developers cannot fix it... _ then it BSOD. This BSOD does not contain a driver info or register dumps, but I'll keep trying to capture it.

idrassi wrote May 1, 2015 at 8:09 AM

Did you check Windows Event Viewer to see if there is anything logged their at the time the BSOD occurred? Their may be some clues that will help understand this.

The error message indicate that VeraCrypt received an error STATUS_IN_PAGE_ERROR or the error 0xeedfade. These errors typically happen because of hardware issue or faulty drivers, but this maybe a side effect of another problem.

For now, I don't see anything obvious that may explain this. Hopefully, you can find some clues in Windows Event Viewer. As for debug versions, in such BSOD situations, it is helpful only if combined with kernel debugging which is not something trivial to do for non developers.

scottX wrote May 7, 2015 at 1:57 PM

Ok. I have installed Intel Rapid Storage driver and I still get the BSOD. I also noticed I cause it by hot inserting a VC enrypted disk so it is not limited to unsupported encrypted volumes (LUKS and Discrypter) as first stated.

I also got a mini-dump from my last crash. See attached zip file

Eventlog shows this event AFTER reboot, but nothing before.

The computer has rebooted from a bugcheck. The bugcheck was: 0x000000f4 (0x0000000000000003, 0xfffffa80089c3b30, 0xfffffa80089c3e10, 0xfffff800031c2940

FYI I used Truecrypt for years with this exact computer and setup and never had the issue.
Then I switched to Discrypter and did not have the issue.
So my guts are telling me this is not a hardware issue on my side.


scottX wrote May 7, 2015 at 6:56 PM

CORRECTION TO 8:57 AM COMMENT...... I have UNINSTALLED THE Intel Rapid Storage driver. so it rules that out as the failure point.

idrassi wrote May 8, 2015 at 12:20 PM

Thank you for the update.
Windbg analysis of the minidump shows that it's a memory access violation reported in winint.exe which in itself doesn't point to any specific culprit.

By the way, what driver are you using for the AHCI controller?

I'm built a debug version that hopefully will display more information on the BSOD screen and the minidump. I'll added some small extra checks to see it it helps.

You can get it from here:
Debugging Details:
PROCESS_OBJECT: fffffa80089c3b30
IMAGE_NAME:  wininit.exe
MODULE_NAME: wininit
FAULTING_MODULE: 0000000000000000 
PROCESS_NAME:  wininit.exe
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
BUGCHECK_STR:  0xF4_C0000005

fffff880`03a21e38 fffff800`03252342 : 00000000`000000f4 00000000`00000003 fffffa80`089c3b30 fffffa80`089c3e10 : nt!KeBugCheckEx
fffff880`03a21e40 fffff800`032085ab : ffffffff`ffffffff fffffa80`09199b50 fffffa80`089c3b30 fffffa80`089c3b30 : nt!PspCatchCriticalBreak+0x92
fffff880`03a21e80 fffff800`031760cc : ffffffff`ffffffff 00000000`00000001 fffffa80`089c3b30 00000000`00000008 : nt! ?? ::NNGAKEGL::`string'+0x2a546
fffff880`03a21ed0 fffff800`02ebdcd3 : fffffa80`089c3b30 fffff800`c0000005 fffffa80`09199b50 00000000`02a00840 : nt!NtTerminateProcess+0xf4
fffff880`03a21f50 fffff800`02eba290 : fffff800`02f3f519 fffff880`03a22a38 fffff880`03a22790 fffff880`03a22ae0 : nt!KiSystemServiceCopyEnd+0x13
fffff880`03a220e8 fffff800`02f3f519 : fffff880`03a22a38 fffff880`03a22790 fffff880`03a22ae0 00000000`02a02350 : nt!KiServiceLinkage
fffff880`03a220f0 fffff800`02ebe0c2 : fffff880`03a22a38 00000000`0000aab7 fffff880`03a22ae0 00000000`02a01e28 : nt! ?? ::FNODOBFM::`string'+0x48554
fffff880`03a22900 fffff800`02ebcc3a : 00000000`00000001 00000000`02a00f58 00000000`00000001 00000000`0000aab7 : nt!KiExceptionDispatch+0xc2
fffff880`03a22ae0 00000000`7775883d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x23a
00000000`02a00f60 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7775883d

FOLLOWUP_NAME:  MachineOwner
FAILURE_BUCKET_ID:  X64_0xF4_C0000005_IMAGE_wininit.exe
BUCKET_ID:  X64_0xF4_C0000005_IMAGE_wininit.exe
Followup: MachineOwner

scottX wrote May 8, 2015 at 2:02 PM

Since I uninstalled Intel Rapid Storage Driver, Win 7 is using the "Microsoft Standard AHCI 1.0 Serial ATA Controller" version 6.1.7601.18231

I'll install your debug version and keep you posted.


idrassi wrote May 23, 2015 at 6:28 PM

Hi Scott,

I just wanted to check if you were able to do tests using the debug version I posted before.


scottX wrote Jun 1, 2015 at 2:32 AM

Well I really have only had one crash since I uninstalled Intel Rapid Storage. I may have narrowed it down a little bit. when you install a new disk Win7 wants to load the device driver for it. When Rapid Storage is installed you don't see the native Win7 sysTray popup showing the disk model number and the "installing device driver". I'm really thinking there is a race condition with VC, Rapid Storage driver and Windows all wanting to read the disk at the same time.


cgp wrote Sep 30, 2016 at 8:19 AM

Hi, I also had several BSOD events with VC installed (1.18a on Win7 pro 64) when unmounting volumes ; if it can help I noted that using VC (same release, x64 exe version) in portable mode, the problem does not happen any more.