It seems i can't mount my encrypted partition since the last major Windows update.
When veracrypt should attach the decrypted volume to a drive, Windows crashes with the error PNP_DETECTED_FATAL_ERROR.
I have tried disabling driver signature verification in the recovery boot menu without success.
I didn't check the minidump but this error reminds me of old problems
encountered when using Symantec Norton Security software
(https://sourceforge.net/p/veracrypt/discussion/technical/thread/dc4f564d/#c31e).
Are you running a Symantec product?
What other security software are using on this machine?
As shown by the recent issue with Acronis software that was causing
BSOD, such issues are rarely caused by VeraCrypt itself but rather by
other software that has compatibility issues with Windows changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not using any Symantec product on my computer.
I'm using Windows Defender as an antivirus and the native firewall.
No other security software is running.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just remembered that the filesystem of the encrypted disk is ReFS.
The stacktrace in the minidump seems to be in the ReFS methods:
nt!KeBugCheckEx
nt!IoGetDevicePropertyData+0x14af9f
ReFS!MsKmeQueryStorageSMR+0x6e
ReFS!CmsVolume::InitializeStorageTier+0x2bb22
ReFS!CmsVolume::Start+0x579
ReFS!MsInitializeVolume+0xa0
ReFS!RefsMountVolume+0x60a
ReFS!RefsCommonFileSystemControl+0x85
ReFS!RefsFspDispatch+0x343
nt!ExpWorkerThread+0x16a
nt!PspSystemThreadStartup+0x55
nt!KiStartSystemThread+0x1c
I also just remembered that with the 1809 update, Microsoft started to remove capabilities to create volumes using ReFS.
Maybe that's linked ?
Last edit: ALec 2018-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Resilient File System (ReFS)
Creation ability will be available in the following editions only: Windows 10 Enterprise and Windows 10 Pro for Workstations. Creation ability will be removed from all other editions. All other editions will have Read and Write ability.
(added: August 17, 2017)
Last edit: Enigma2Illusion 2018-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just had time to analyze the dump and indeed the BSOD is caused by ReFS driver. To me, it looks like the function IoGetDevicePropertyData is called with an invalid PDO (physical device object) and that's why the bug check happens.
After the volume is successfully unlocked by VeraCrypt, VeraCrypt driver calls the Windows Mount Manager and from there control is transferred to ReFS driver to perform the actual mount. During this, ReFS driver performs the call chain seen on the memory dump.
I suspect that the latest version of ReFS is trying to access some properties that exist only on physical disks and it doesn't properly validate the parameters associated with the VeraCrypt virtual disk before calling IoGetDevicePropertyData. Instead of crashing, ReFS should
just refuse to handle the VeraCrypt volume.
ReFS is already not supported on removable media (https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview#the-following-features-are-unavailable-on-refs-at-this-time) so it looks like now VeraCrypt virtual disks are also not supported anymore (although in a real hard way!).
I don't think there is a solution for such ReFS driver issue but I will try to spend more time on it. If nothing can be done to avoid such BSOD, I will simply disable mounting ReFS volumes on Wondows 10 1809 at least until Microsoft replace the BSOD with a simple error message...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For advanced users, it should still be possible to use ReFS with VeraCrypt by using software which emulates an actual physical disk such as Arsenal Image Mounter (see here https://sourceforge.net/p/veracrypt/discussion/features/thread/9cc3fd9e67/)
Too bad the way AIM is licensed now, I doubt it can be easily integrated into any VC workflow for anyone other than end users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to reproduce the crash with an ReFS volume and a quick analysis confirms what I suspected above. I will need to look deeper into it in case I missed something but I am not very optimistic about this compatibility problem.
@neos6464: thank you for sharing the idea of using Arsenal Image Mounter and sorry for not giving any feedback to your previous post about it.
Actually, I have looked at Arsenal Image Mounter 1 year ago when I was looking for ways to implement an emulation of real physical disks to fix Windows issue that started to appear. Their implementation is very good and the efforts to code something similar is huge. Unfortunately, their license does not allow their code to be included in VeraCrypt so I stopped exploring more this way.
Using their command line tool is a good idea but it works only for unformatted volumes. For existing volumes, this idea will not fix the crash.
One way to make Arsenal Image Mounter integrates easily with VeraCrypt is to add an option to VeraCrypt drive to skip the call of Windows Mount Manager and just create the virtual device and after that the user can call manually the AIM command line tool to perform the real mount. Such option already exists on Linux so adding it to Windows makes sens.
Moreover, to make life easier for users who need this, one idea is to add the possibility in VeraCrypt to run custom commands once a volume is mounted (this was proposed on the forum previously). This way, the whole process will be smooth. Of course, this supposes that the user trusts AIM with his senstive data.
All this requires time to do...I will let you know when I have something to test.
👍
1
Last edit: Mounir IDRASSI 2018-11-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To get my data back, i have installed an old win10 version.
I was able to mount the encrypted disk but windows tells me that i must format the disk to use it.
I'm somewhat lost here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
try to explore the content of the mounted volume at sector level using tools like HxD. Normally you should find plain text data (e.g. file names). Maybe Windows is complaining because it's a newer version of ReFS that it does not support. I don't have other explanation. Hopefully Windows 1809 did not cause any damage to the disk content during the BSOD, only low level exploration of the mounted volume could tell.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can explore the physical encrypted partition just fine but it's encrypted.
I can't explore the logical partition once mounted.
HxD tells me "Not enough rights", even when Run as Admin is used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You must have done something wrong because it is working here: I simply
navigated to the location of HxD.exe and right click on it and I
selected "Run as Administrator" from the menu, then I selected the menu
Tools -> Open Disk in HxD and I selected the mounted volume under
"Logical Disks" (not "Physical disks"). From there, I could see the
content of the mounted volume.
Are you sure that you got the UAC prompt when you run HxD.exe as an
administrator?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Retried it 5 minutes ago to be sure.
Here is what i got :
The error message litterally translates to "Insufficient rights to open this disk, even as administrator."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is going to be a Microsoft ownership and/or permission issue likely due to the user ID number (SID) is different than the old user ID number the previous Windows OS was using for your user name.
You may need to set the permissions and ownership on the dismounted VeraCrypt drive/partition. Then mount the VeraCrypt volume. Set the permissions and ownership of all the files within the file container.
Different folders can have different permissions and ownership permissions for user accounts in Windows that are inherited when you place a file in that folder.
Google search Windows permissions and ownership on files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not working, even windows don't know what to do with this volume.
C:\Windows\system32>icacls "O:" /setowner "Administrateurs" /T /C
O:: Le volume ne contient pas de système de fichiers connu. Vérifiez si tous les pilotes de système
de fichiers nécessaires sont chargés et si le volume n’est pas endommagé.
0 fichiers correctement traités ; échec du traitement de 1 fichiers
Translates to:
C:\Windows\system32>icacls "O:" /setowner "Administrators" /T /C
O:: This volume doesn't contain any known filesystem. Check if all necessary drivers are loaded and if the volume isn't corrupted.
0 file handled successfully ; failed to handle 1 file
Last edit: ALec 2018-12-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
can you please create a dummy test file container using VeraCrypt on this machine (formatted as FAT), then mount it and see if you can access its content using HxD?
I suspect that there is something on this machine that blocks access to VeraCrypt volume at low level (\Device\VeraCryptVolume). On standard Windows machines, it is always possible to access the mounted volume using HxD and I have never encuntered a case before it can not do so.
For the icacls error, this is normal since your volume does not look formatted to Windows and that is why we are using HxD to try to understand what is wrong with your setup!
Without access to your machine, it is difficult to know what is happening. I would suggest to use another machine to mount the disk and then use HxD there to explore the volume content. Meanwhile, let us see the result of your test using a dummy file container.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Working fine on both windows installations with a simple file container.
Was able to see the content of my testing text document in HxD ran as admin too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, now I understand what is happening: eventhough VeraCrypt has successfully mounted the disk on the given drive letter, Windows Mount Manager did not perform the actual mount operation and so any access using the drive letter will always fail.
Certainly, Windows Mount Manager did not perform the mount because it does not recognize the ReFS version used on the disk (it behaves similarly on any unknown filesystem).
HxD does not handle correcly this situation since it should perform access using the device name instead on the drive letter.
I have written a quick implementation of a command line tool that can read data of mounted volume even if Windows Mount Manager did not perform the mount. The tool requires administrative privileges and it takes drive letter as argument (without argument, it asks for drive letter to use). After that, it will dump the first 512 bytes of the volume and then it will ask for offset to use for reading.
Can you please use this tool to check the content of your mounted disk? It will help confirm that the disk content is OK and that the issue is caused by ReFS version compatibility.
Wans't able to find a lot of thing in clear text (like filenames) but that's not so surprising given the volume content: mainly videos and photos so lots of binary content.
I'm actually updating my testing windows installation to 1803 which is the last version where i was able to read the data successfully to see if i'm able to get my data back by copying.
It's gonna take a while because it's running on an old hard drive so no news before tomorrow night.
Thank you for your help this far.
Last edit: ALec 2018-12-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the first 512 bytes of your volume, the version of ReFS used is 3.4 which means that you need Windows10 1803 to be able to read it. This explains everything since older versions of Windows will not recognize the filesystem.
Updating to 1803 will definitely fix the issue and you will be able to access the data.
As for the original problem on 1809, I'm still trying to find new ideas to fix it or at least setup an alternative way for people affected to be able to access their data with BSOD.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To continue this saga, the latest updates after Windows 10 1809 installation correct the blue screen problem but now I get a "drive not accessible" error, "The volume does not contain a recognized file system". The disk is using ReFS on Windows 10 Enterprise so I have ReFS installed and also have a non-encrypted drive using ReFS that is working normally. Anything I can do to force loading ReFS on encrypted disks?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Michel for the information about Microsoft fix.
Indeed, KB4471332 includes a fix for the ReFS.sys driver and this is certainly related to this BSOD. Now, ReFS returns an error instead of crashing but it still continues to refuse to use VeraCrypt virtual volumes.
I still could not find any workaround for this new ReFS limitation but I'm not giving up.
For the time being, for those who need to access the data on their ReFS formatted volumes, the solution proposed by neos6464 through Arsenal Image Mounter works but its license allows it only for personal use. Here the steps to use it with a VeraCrypt volume:
Install the driver using the setup at "Arsenal-Image-Mounter-master\DriverSetup\ArsenalImageMounterGUISetup.exe"
Open a command prompt as an administrator and navigate to the folder "Arsenal-Image-Mounter-master\Command line applications"
Mount your ReFS formatted disk in VeraCrypt. We suppose it is mounted at the letter X.
Type the following two commands in the previously opened command prompt:
mountvol X: /D
aim_ll -a -F \Device\VeraCryptVolumeX -o ro (replace X in VeraCryptVolumeX by the drive letter used, for example VeraCryptVolumeZ if Z: used)
After that, a new driver letter will be created and it will hold the data of the ReFS volume.
The last command mounts the volume as ReadOnly. If you are confident about this setup, then you can remove the last option -o ro and just type aim_ll -a -F \Device\VeraCryptVolumeX.
I will post later on this thread about my progress on this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info! I installed the newest Windows 10 update and now we're back to the blue screen so I can't test your solution... Thanks Microsoft for messing with what worked fine before...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have implemented a new feature in 1.24-Beta0 that allows mounting volumes without actually attaching them to the drive letter. This will avoid the Windows BSOD and the solution proposed above will work since the mounted volume can be accessed using its low level device path \Device\VeraCryptVolumeX (X being the drive letter chosen for mounting even if it is not actually associated with it in Windows).
Below is a screenshot of this new mount option and you can get the installer from the Nightly Builds folder.
Anyway, we are like playing cat and mouse with Microsoft...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
It seems i can't mount my encrypted partition since the last major Windows update.
When veracrypt should attach the decrypted volume to a drive, Windows crashes with the error PNP_DETECTED_FATAL_ERROR.
I have tried disabling driver signature verification in the recovery boot menu without success.
I have attached the corresponding minidump.
Hi,
I didn't check the minidump but this error reminds me of old problems
encountered when using Symantec Norton Security software
(https://sourceforge.net/p/veracrypt/discussion/technical/thread/dc4f564d/#c31e).
Are you running a Symantec product?
What other security software are using on this machine?
As shown by the recent issue with Acronis software that was causing
BSOD, such issues are rarely caused by VeraCrypt itself but rather by
other software that has compatibility issues with Windows changes.
I'm not using any Symantec product on my computer.
I'm using Windows Defender as an antivirus and the native firewall.
No other security software is running.
I just remembered that the filesystem of the encrypted disk is ReFS.
The stacktrace in the minidump seems to be in the ReFS methods:
nt!KeBugCheckEx
nt!IoGetDevicePropertyData+0x14af9f
ReFS!MsKmeQueryStorageSMR+0x6e
ReFS!CmsVolume::InitializeStorageTier+0x2bb22
ReFS!CmsVolume::Start+0x579
ReFS!MsInitializeVolume+0xa0
ReFS!RefsMountVolume+0x60a
ReFS!RefsCommonFileSystemControl+0x85
ReFS!RefsFspDispatch+0x343
nt!ExpWorkerThread+0x16a
nt!PspSystemThreadStartup+0x55
nt!KiStartSystemThread+0x1c
I also just remembered that with the 1809 update, Microsoft started to remove capabilities to create volumes using ReFS.
Maybe that's linked ?
Last edit: ALec 2018-11-28
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-fall-creators-deprecation
Last edit: Enigma2Illusion 2018-11-28
Thank you both for these details.
I just had time to analyze the dump and indeed the BSOD is caused by ReFS driver. To me, it looks like the function IoGetDevicePropertyData is called with an invalid PDO (physical device object) and that's why the bug check happens.
After the volume is successfully unlocked by VeraCrypt, VeraCrypt driver calls the Windows Mount Manager and from there control is transferred to ReFS driver to perform the actual mount. During this, ReFS driver performs the call chain seen on the memory dump.
I suspect that the latest version of ReFS is trying to access some properties that exist only on physical disks and it doesn't properly validate the parameters associated with the VeraCrypt virtual disk before calling IoGetDevicePropertyData. Instead of crashing, ReFS should
just refuse to handle the VeraCrypt volume.
ReFS is already not supported on removable media (https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview#the-following-features-are-unavailable-on-refs-at-this-time) so it looks like now VeraCrypt virtual disks are also not supported anymore (although in a real hard way!).
I don't think there is a solution for such ReFS driver issue but I will try to spend more time on it. If nothing can be done to avoid such BSOD, I will simply disable mounting ReFS volumes on Wondows 10 1809 at least until Microsoft replace the BSOD with a simple error message...
For advanced users, it should still be possible to use ReFS with VeraCrypt by using software which emulates an actual physical disk such as Arsenal Image Mounter (see here https://sourceforge.net/p/veracrypt/discussion/features/thread/9cc3fd9e67/)
Too bad the way AIM is licensed now, I doubt it can be easily integrated into any VC workflow for anyone other than end users.
I was able to reproduce the crash with an ReFS volume and a quick analysis confirms what I suspected above. I will need to look deeper into it in case I missed something but I am not very optimistic about this compatibility problem.
@neos6464: thank you for sharing the idea of using Arsenal Image Mounter and sorry for not giving any feedback to your previous post about it.
Actually, I have looked at Arsenal Image Mounter 1 year ago when I was looking for ways to implement an emulation of real physical disks to fix Windows issue that started to appear. Their implementation is very good and the efforts to code something similar is huge. Unfortunately, their license does not allow their code to be included in VeraCrypt so I stopped exploring more this way.
Using their command line tool is a good idea but it works only for unformatted volumes. For existing volumes, this idea will not fix the crash.
One way to make Arsenal Image Mounter integrates easily with VeraCrypt is to add an option to VeraCrypt drive to skip the call of Windows Mount Manager and just create the virtual device and after that the user can call manually the AIM command line tool to perform the real mount. Such option already exists on Linux so adding it to Windows makes sens.
Moreover, to make life easier for users who need this, one idea is to add the possibility in VeraCrypt to run custom commands once a volume is mounted (this was proposed on the forum previously). This way, the whole process will be smooth. Of course, this supposes that the user trusts AIM with his senstive data.
All this requires time to do...I will let you know when I have something to test.
Last edit: Mounir IDRASSI 2018-11-29
To get my data back, i have installed an old win10 version.
I was able to mount the encrypted disk but windows tells me that i must format the disk to use it.
I'm somewhat lost here.
try to explore the content of the mounted volume at sector level using tools like HxD. Normally you should find plain text data (e.g. file names). Maybe Windows is complaining because it's a newer version of ReFS that it does not support. I don't have other explanation. Hopefully Windows 1809 did not cause any damage to the disk content during the BSOD, only low level exploration of the mounted volume could tell.
I can explore the physical encrypted partition just fine but it's encrypted.
I can't explore the logical partition once mounted.
HxD tells me "Not enough rights", even when Run as Admin is used.
You must have done something wrong because it is working here: I simply
navigated to the location of HxD.exe and right click on it and I
selected "Run as Administrator" from the menu, then I selected the menu
Tools -> Open Disk in HxD and I selected the mounted volume under
"Logical Disks" (not "Physical disks"). From there, I could see the
content of the mounted volume.
Are you sure that you got the UAC prompt when you run HxD.exe as an
administrator?
Retried it 5 minutes ago to be sure.
Here is what i got :
The error message litterally translates to "Insufficient rights to open this disk, even as administrator."
This is going to be a Microsoft ownership and/or permission issue likely due to the user ID number (SID) is different than the old user ID number the previous Windows OS was using for your user name.
You may need to set the permissions and ownership on the dismounted VeraCrypt drive/partition. Then mount the VeraCrypt volume. Set the permissions and ownership of all the files within the file container.
https://www.windowscentral.com/how-take-ownership-files-and-folders-windows-10
Different folders can have different permissions and ownership permissions for user accounts in Windows that are inherited when you place a file in that folder.
Google search Windows permissions and ownership on files.
Not working, even windows don't know what to do with this volume.
Translates to:
Last edit: ALec 2018-12-04
can you please create a dummy test file container using VeraCrypt on this machine (formatted as FAT), then mount it and see if you can access its content using HxD?
I suspect that there is something on this machine that blocks access to VeraCrypt volume at low level (\Device\VeraCryptVolume). On standard Windows machines, it is always possible to access the mounted volume using HxD and I have never encuntered a case before it can not do so.
For the icacls error, this is normal since your volume does not look formatted to Windows and that is why we are using HxD to try to understand what is wrong with your setup!
Without access to your machine, it is difficult to know what is happening. I would suggest to use another machine to mount the disk and then use HxD there to explore the volume content. Meanwhile, let us see the result of your test using a dummy file container.
Working fine on both windows installations with a simple file container.
Was able to see the content of my testing text document in HxD ran as admin too.
Ok, now I understand what is happening: eventhough VeraCrypt has successfully mounted the disk on the given drive letter, Windows Mount Manager did not perform the actual mount operation and so any access using the drive letter will always fail.
Certainly, Windows Mount Manager did not perform the mount because it does not recognize the ReFS version used on the disk (it behaves similarly on any unknown filesystem).
HxD does not handle correcly this situation since it should perform access using the device name instead on the drive letter.
I have written a quick implementation of a command line tool that can read data of mounted volume even if Windows Mount Manager did not perform the mount. The tool requires administrative privileges and it takes drive letter as argument (without argument, it asks for drive letter to use). After that, it will dump the first 512 bytes of the volume and then it will ask for offset to use for reading.
Can you please use this tool to check the content of your mounted disk? It will help confirm that the disk content is OK and that the issue is caused by ReFS version compatibility.
The tool is available at https://www.veracrypt.fr/downloads/tools/vcHexViewer.zip
The exe files inside the zip are signed using the same IDRIX code signing certificates used to sign VeraCrypt. The pgp signature of the zip is available at https://www.veracrypt.fr/downloads/tools/vcHexViewer.zip.sig
Thank you in advance for your feedback.
Last edit: Mounir IDRASSI 2018-12-05
I'm able to read data this way.
First sector :
Some random sector with clear data :
Wans't able to find a lot of thing in clear text (like filenames) but that's not so surprising given the volume content: mainly videos and photos so lots of binary content.
I'm actually updating my testing windows installation to 1803 which is the last version where i was able to read the data successfully to see if i'm able to get my data back by copying.
It's gonna take a while because it's running on an old hard drive so no news before tomorrow night.
Thank you for your help this far.
Last edit: ALec 2018-12-05
Thanks for the feedback.
From the first 512 bytes of your volume, the version of ReFS used is 3.4 which means that you need Windows10 1803 to be able to read it. This explains everything since older versions of Windows will not recognize the filesystem.
Updating to 1803 will definitely fix the issue and you will be able to access the data.
As for the original problem on 1809, I'm still trying to find new ideas to fix it or at least setup an alternative way for people affected to be able to access their data with BSOD.
I'm able to get my data back in Windows10 1803.
Thank you for the support.
Edit: I'm not able to edit the thread's title to indicate it is solved or I'm blind maybe.
Last edit: ALec 2018-12-06
To continue this saga, the latest updates after Windows 10 1809 installation correct the blue screen problem but now I get a "drive not accessible" error, "The volume does not contain a recognized file system". The disk is using ReFS on Windows 10 Enterprise so I have ReFS installed and also have a non-encrypted drive using ReFS that is working normally. Anything I can do to force loading ReFS on encrypted disks?
Thank you Michel for the information about Microsoft fix.
Indeed, KB4471332 includes a fix for the ReFS.sys driver and this is certainly related to this BSOD. Now, ReFS returns an error instead of crashing but it still continues to refuse to use VeraCrypt virtual volumes.
I still could not find any workaround for this new ReFS limitation but I'm not giving up.
For the time being, for those who need to access the data on their ReFS formatted volumes, the solution proposed by neos6464 through Arsenal Image Mounter works but its license allows it only for personal use. Here the steps to use it with a VeraCrypt volume:
mountvol X: /D
aim_ll -a -F \Device\VeraCryptVolumeX -o ro
(replace X in VeraCryptVolumeX by the drive letter used, for example VeraCryptVolumeZ if Z: used)After that, a new driver letter will be created and it will hold the data of the ReFS volume.
The last command mounts the volume as ReadOnly. If you are confident about this setup, then you can remove the last option
-o ro
and just typeaim_ll -a -F \Device\VeraCryptVolumeX
.I will post later on this thread about my progress on this issue.
Thanks for the info! I installed the newest Windows 10 update and now we're back to the blue screen so I can't test your solution... Thanks Microsoft for messing with what worked fine before...
I have implemented a new feature in 1.24-Beta0 that allows mounting volumes without actually attaching them to the drive letter. This will avoid the Windows BSOD and the solution proposed above will work since the mounted volume can be accessed using its low level device path \Device\VeraCryptVolumeX (X being the drive letter chosen for mounting even if it is not actually associated with it in Windows).
Below is a screenshot of this new mount option and you can get the installer from the Nightly Builds folder.
Anyway, we are like playing cat and mouse with Microsoft...