Menu

(Solved) PNP_DETECTED_FATAL_ERROR since Win10 Oct 2018 Update

ALec
2018-11-27
2020-05-11
1 2 > >> (Page 1 of 2)
  • ALec

    ALec - 2018-11-27

    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.

     
    • Mounir IDRASSI

      Mounir IDRASSI - 2018-11-28

      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.

       
  • ALec

    ALec - 2018-11-28

    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.

     
  • ALec

    ALec - 2018-11-28

    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
  • Enigma2Illusion

    Enigma2Illusion - 2018-11-28

    https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-fall-creators-deprecation

    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
  • Mounir IDRASSI

    Mounir IDRASSI - 2018-11-29

    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...

     
  • neos6464

    neos6464 - 2018-11-29

    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.

     
  • Mounir IDRASSI

    Mounir IDRASSI - 2018-11-29

    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
  • ALec

    ALec - 2018-12-01

    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.

     
  • Mounir IDRASSI

    Mounir IDRASSI - 2018-12-01

    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.

     
  • ALec

    ALec - 2018-12-02

    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.

     
    • Mounir IDRASSI

      Mounir IDRASSI - 2018-12-03

      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?

       
  • ALec

    ALec - 2018-12-03

    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."

     
  • Enigma2Illusion

    Enigma2Illusion - 2018-12-04

    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.

     
  • ALec

    ALec - 2018-12-04

    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
  • Mounir IDRASSI

    Mounir IDRASSI - 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.

     
  • ALec

    ALec - 2018-12-04

    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.

     
  • Mounir IDRASSI

    Mounir IDRASSI - 2018-12-05

    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
  • ALec

    ALec - 2018-12-05

    I'm able to read data this way.
    First sector :

    Device Path = \Device\VeraCryptVolumeO
    Device opened successfully.
    Reading first 512 bytes:
    ----------------------------------------------------------
    0000000000000000| 00 00 00 52 65 46 53 00 00 00 00 00 00 00 00 00 | ...ReFS.........
    0000000000000010| 46 53 52 53 00 02 60 69 00 00 4E C3 00 00 00 00 | FSRS..`i..N├....
    0000000000000020| 00 02 00 00 08 00 00 00 03 04 00 00 0A 00 00 00 | ................
    0000000000000030| 00 00 00 00 00 00 00 00 27 54 6B 66 60 6B 66 42 | ........'Tkf`kfB
    0000000000000040| 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000050| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000060| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000070| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000080| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000090| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000000A0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000000B0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000000C0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000000D0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000000E0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000000F0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000100| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000110| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000120| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000130| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000140| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000150| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000160| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000170| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000180| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    0000000000000190| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000001A0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000001B0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000001C0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000001D0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000001E0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    00000000000001F0| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
    

    Some random sector with clear data :

    Reading 512 bytes from offser 0x000000BEBCBC4600:
    ----------------------------------------------------------
    000000BEBCBC4600| 32 37 42 37 42 34 30 30 46 30 38 34 44 44 31 31 | 27B7B400F084DD11
    000000BEBCBC4610| 39 41 30 38 41 43 43 46 35 42 31 36 39 44 30 31 | 9A08ACCF5B169D01
    000000BEBCBC4620| 3C 2F 73 74 52 65 66 3A 64 6F 63 75 6D 65 6E 74 | </stRef:document
    000000BEBCBC4630| 49 44 3E 0A 20 20 20 20 20 20 20 20 20 3C 2F 78 | ID>.         </x
    000000BEBCBC4640| 61 70 4D 4D 3A 44 65 72 69 76 65 64 46 72 6F 6D | apMM:DerivedFrom
    000000BEBCBC4650| 3E 0A 20 20 20 20 20 20 3C 2F 72 64 66 3A 44 65 | >.      </rdf:De
    000000BEBCBC4660| 73 63 72 69 70 74 69 6F 6E 3E 0A 20 20 20 20 20 | scription>.
    000000BEBCBC4670| 20 3C 72 64 66 3A 44 65 73 63 72 69 70 74 69 6F |  <rdf:Descriptio
    000000BEBCBC4680| 6E 20 72 64 66 3A 61 62 6F 75 74 3D 22 22 0A 20 | n rdf:about="".
    000000BEBCBC4690| 20 20 20 20 20 20 20 20 20 20 20 78 6D 6C 6E 73 |            xmlns
    000000BEBCBC46A0| 3A 64 63 3D 22 68 74 74 70 3A 2F 2F 70 75 72 6C | :dc="http://purl
    000000BEBCBC46B0| 2E 6F 72 67 2F 64 63 2F 65 6C 65 6D 65 6E 74 73 | .org/dc/elements
    000000BEBCBC46C0| 2F 31 2E 31 2F 22 3E 0A 20 20 20 20 20 20 20 20 | /1.1/">.
    000000BEBCBC46D0| 20 3C 64 63 3A 66 6F 72 6D 61 74 3E 69 6D 61 67 |  <dc:format>imag
    000000BEBCBC46E0| 65 2F 6A 70 65 67 3C 2F 64 63 3A 66 6F 72 6D 61 | e/jpeg</dc:forma
    000000BEBCBC46F0| 74 3E 0A 20 20 20 20 20 20 3C 2F 72 64 66 3A 44 | t>.      </rdf:D
    000000BEBCBC4700| 65 73 63 72 69 70 74 69 6F 6E 3E 0A 20 20 20 20 | escription>.
    000000BEBCBC4710| 20 20 3C 72 64 66 3A 44 65 73 63 72 69 70 74 69 |   <rdf:Descripti
    000000BEBCBC4720| 6F 6E 20 72 64 66 3A 61 62 6F 75 74 3D 22 22 0A | on rdf:about="".
    000000BEBCBC4730| 20 20 20 20 20 20 20 20 20 20 20 20 78 6D 6C 6E |             xmln
    000000BEBCBC4740| 73 3A 70 68 6F 74 6F 73 68 6F 70 3D 22 68 74 74 | s:photoshop="htt
    000000BEBCBC4750| 70 3A 2F 2F 6E 73 2E 61 64 6F 62 65 2E 63 6F 6D | p://ns.adobe.com
    000000BEBCBC4760| 2F 70 68 6F 74 6F 73 68 6F 70 2F 31 2E 30 2F 22 | /photoshop/1.0/"
    000000BEBCBC4770| 3E 0A 20 20 20 20 20 20 20 20 20 3C 70 68 6F 74 | >.         <phot
    000000BEBCBC4780| 6F 73 68 6F 70 3A 43 6F 6C 6F 72 4D 6F 64 65 3E | oshop:ColorMode>
    000000BEBCBC4790| 33 3C 2F 70 68 6F 74 6F 73 68 6F 70 3A 43 6F 6C | 3</photoshop:Col
    000000BEBCBC47A0| 6F 72 4D 6F 64 65 3E 0A 20 20 20 20 20 20 20 20 | orMode>.
    000000BEBCBC47B0| 20 3C 70 68 6F 74 6F 73 68 6F 70 3A 49 43 43 50 |  <photoshop:ICCP
    000000BEBCBC47C0| 72 6F 66 69 6C 65 3E 73 52 47 42 20 49 45 43 36 | rofile>sRGB IEC6
    000000BEBCBC47D0| 31 39 36 36 2D 32 2E 31 3C 2F 70 68 6F 74 6F 73 | 1966-2.1</photos
    000000BEBCBC47E0| 68 6F 70 3A 49 43 43 50 72 6F 66 69 6C 65 3E 0A | hop:ICCProfile>.
    000000BEBCBC47F0| 20 20 20 20 20 20 20 20 20 3C 70 68 6F 74 6F 73 |          <photos
    

    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
  • Mounir IDRASSI

    Mounir IDRASSI - 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.

     
  • ALec

    ALec - 2018-12-06

    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
  • Michel Ferland

    Michel Ferland - 2018-12-17

    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?

     
  • Mounir IDRASSI

    Mounir IDRASSI - 2018-12-17

    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:

    • Download the latest Arsenal Image Mounter package from Github: https://github.com/ArsenalRecon/Arsenal-Image-Mounter/archive/master.zip
    • Unzip the archive in a location of your choice.
    • 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.

     
  • Michel Ferland

    Michel Ferland - 2018-12-20

    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...

     
  • Mounir IDRASSI

    Mounir IDRASSI - 2018-12-20

    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...

    VeraCrypt Mount Option

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.