8382 error after reboot from Win10 21H1 x64 KB5007186
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Using Veracrypt on many machines and since truecrypt days, mainly without incident or issue, but got a problem I can't solve or find much information about. Error 8382. Win10x64
The only factor that MIGHT be related is a reboot from MS update Win10 21H1 x64 aka KB5007186
Otherwise on restarting the partition will not mount. Password has not changed in years, know it by heart and via roboform PW manager. Was on 1.24 Up7, re-installed to be sure. x64
Tried using the existing favourite mount and manual, but nothing. It's native Veracrypt, not TrueCrypt.
Are there any recovery options? Or potential ways to rectify this?
Any idea why/what has happened?
Thanks
Small update for anyone suffering similar issues, the PC has other partitions, not updated and booting to one of those allows the partition to mount without issue. So this appears to be related to some change with the instance of Win10x64 either from that update mentioned or some other issue, although VC was re-installed as a "repair" to no improvement.
Rebooted to the main partition where the fault is evident.
Uninstalled Veracrypt, and restarted machine, downloaded fresh copy from .fr site (1.24-Update7 Friday August 7, 2020) reinstalled (no restart requested)
Issue remains,
So I can now say with some certainty that the separate SSD that the veracrypt partition is on is not at fault, as it works fine on the same machine via a different W10x64 boot.
So some form of conflict or something in the latest MS updates?
Any help would be really appreciated.
If this behavior is clearly reproducible by only installing the Windows update in question, you would be better off with creation of an error ticket, as the update maybe changed something which would affect VC.
Greets
I have had the exact same thing on another machine, fine before this update and exact same error directly after the restarting post update, on this machine it is two volumes on 2 different drives.
So now TWO pc's with 3 Veracrypt volumes
On the first machine removing (uninstalling) the updates did not help, not re-installing them, nor re-re-installing Veracrypt
There seems to be a major issue coming, any help would be appreciated
Sorry for cross post, but not sure best place to continue this ...
Hi, having stripped the desktop in question to remove the drive to try and read on another machine (as that PC has no dual boot), I am now getting the following err or when attempting to mount on a working Veracrypt instance (the same dual boot PC that has 1 partition unable to read and 1 partition that can read it's own VC partition.
The error is :
The device is not ready.
Source: MountVolume:8048
Searching for this I find references to Paragon HFS and Mac disk reading ... which I had recently done to recover some drives, on the Desktop and one the one partion of the dual boot that's also playing up. So I think I can say there is a high chance this is part of the issue??
Next, the good booting partition of the dual boot, that would read the VC partition on it's existing drive, will NOT read via external USB interface either of two HDD's from the desktop, the error is the 8048 for both. That booting partition never had any instance of HFS or similar Mac software on it, and it does read the internal shared partition that refuses to read within the HFS contaminated boot partition. Hope that makes sense?!
Tried on another laptop that never had HFS at all and it's own VC volume has been stable, and that also give the 8048 error.
SO I now have two volumes (two HDD) that I appear to be unable to mount and read, regardless of HFS presence on the OS.
With HFS and all other Mac based stuff removed/uninstalled from original PC and it's rebooted etc, trying to mount either of the volumes I get the original 8382 rather than 8048!
Any pointers or possible patches to enable these volumes to be read?
Thanks
Finally have a laptop that will mount the drives without errors, but it seems like using the HFS (not a new concern based on google searches to find my own solution) is the likely cause.
The Dual booting machine, on the HFS "clean" partition worked ... a reboot (sadly including the current windows updates) then worked and mounted the partitions ... Why this partition could not read the VC volumes prior to the reboot I have no idea. It had been rebooted many times in the last 3-4 days
just got 20tb of data to move now :-( then conflict resolution and merge new data :-(
I am a little disheartened by the lack of interest or help, which does undermine any project and erodes faith and trust in using something as "key and core" to your data's availablity
This has the potential to screw up a seriously large dataset, and while only 1-2gb of the data is not on the last backup, the disruption and the time consuming task to reconcile the data caused is immense.
So, sadly reconsidering my ongoing use of Veracrypt and will probably drop it as cannot be left in such a precarious position with no realistic expectation of any support .... shame, but cannot afford to be put in the same position like this again. I only hope this helps someone else in the future suffering HFS/Mac conflict issues and encourages people to step up or call out the lack of support.
I'm a bit confused. We've been talking about Windows all the time, and now it's about a Mac filesystem. Some knowledge about this could have changed the way to handle the issue. Maybe it's still just an issue with Windows, as HFS is (afaik) not natively supported by Windows. I would be interested in how this worked until the issue occurred. Maybe something broke due to the mentioned update?
Additionally, please be so kind to keep in mind, that this is an open-source project which lives by the people who use the software and try to help each other out when an issue occurs. I, for my part, put my free time into trying to help other users. Of course, this fact can delay response to requests for help. Especially, when free time is limited.
Greets
Sorry you've mis-understood.
It's Windows10x64
I had installed the Paragon (and other) HFS and APFS drive readers, for use under windows to recover data from a native and straight Mac formed drive (not Veracrypt related or encrypted).
It is these drivers/utilities that seem to have a historic and clearly ongoing issue with VC integrity or the ability to corrupt/mask/interfere with the ability for VC to mount otherwise perfectly fine volumes from ongoing operation under windows.
The VC partition had NO involvement with MAC other than being mounted during the paragon (and others) HFS/APFS drivers install and operation on unrelated externally mounted hard drives.
I hope this is clear, the VC volumes were resident before and after, their failure to mount is related to the Mac drivers used to read completely different media.
This SHOULD not be a reason for VC to fail to mount, or generate errors, as the volumes are intact and can be read (with major trial and error) on other machines. Clearly there is a huge conflict and it's not a native issue to VC but the conflict exists and has been previously reported but persists and no help is forthcoming or pointers.
It's a shame, but I'm out of VC, this sort of issue and lack of concern for correcting known conflicts leaves a very bad taste.
Alright, now the situation becomes more clearly. However, in my opinion, your criticism of VeraCrypt is inappropriate. VeraCrypt is not at fault if the drivers of a proprietary software interferes with VeraCrypt's functionality. In this case, it would be more advisable to ask the developer of the interfering software to resolve a possible bug / interference within their software, which affects other software from a similar software category, which would be something like file system emulation (I don't know the exact mechanics of both software tools).
It is also possible that both, VeraCrypt's and the driver of the other software, use the same or similar driver interfaces and that it's just not possible to load both at the same time. In case of Paragon, they had the opportunity to review VeraCrypt's code base to find a solution for such issue. The other way around it's not possible, as e.g. Paragon is closed source and there's no way to review their code. In my opinion, you blame the wrong project.
As Paragon is paid software, you should, as a paying customer, ask for appropriate support by your vendor. That's what they get paid for, after all.
Greets
Hi, I'm not saying who is paid or not, both software have to resolve the issues to be safe and sure no other software will conflict. It's a dual issue, not one sided. VC or Paragon.
The issue as it unfolds is that VC was made aware of issues with Paragon HFS+ some time ago, but nothing seems to have been done. Paragon probably don't care as their product works and is not diminished in the conflict, they feel they have nothing to fix. Their HFS+ works just dandy.
VC however even post uninstall of all related software, VC and Paragon (I have both HFS and APFS as well as at least 3 other MAC disk tools installed to try and recover the external drive - so could be any of them, google will give you a list!), and purely re-install of VC, the volumes are still not accessible.
**This is my issue. **
Further that the issue appears to have corrupted or caused the volume (container) to have been modified to affect it's readability, even on "clean" systems.
The fact that the volumes were not readable of other never compromised PC's that are using VC just fine on their normal volumes, and it took a random number of machines before I could get the Volume to read, is a sign of some inconsistencies or randomness that needs to be solved, or at least a tool to read and repair the damage.
Inconsistent operation is always a concern as to robustness and integrity. Just saying.
Clearly Paragon don't care about anything other than their own code functioning, which it did and does so they will not care to fix a conflict with VC. Why would they? Seriously, to say they should and the problem is theirs to solve is, both naive and petty ... please get real.
VC operation is compromised to the point of FAILURE and CORRUPTION from the conflict, maybe you should care and take notice, whoever's code is to blame is not the point, the conflict is there and has been reported, ignoring it is not an outcome. That's abdication of responsibility.
I'm not the first to raise this, and the lack of details of what the error codes might mean is also a lacking aspect of the documentation. It made my life very hard to pin point the possible issues and root cause. This might have been much easier if the errors were documented ... do you want Paragon to do that for you too?
I'm posting this only to help others in my position find answers, and to try and coax and encourage the project team to take some steps to investigate and reproduce the issues so they might be fixed. While the conflict is rare, knowing and leaving it and not warning people (adding documentation about the errors and the known conflict/bug) is courting disaster for some poor persons data. Shame.
This is my last post, I've got all my data read onto non-VC containers and after this experience will likely never use VC again. Such a shame to see a great project reach this point of indifference.
I agree with you regarding lack of documentation of error codes. But I still don't know what software A can do if software B jams functionality of software A without any care. Especially if software B is proprietary software (no chance to get a look at the code to pinout anything out). In such a case we are talking about bad behavior of software B then. If it was vice versa, and VeraCrypt would disrupt other software, people would still blame this project. It's easy to blackguard free and open-source software projects.
As this is complex software, it is likely to have bugs, like any other software — of course! If there would be inconsistency in behavior, it should be addressed — of course! But, as far as I know, there is currently no evidence for inconsistent behavior. There were code reviews of at least one federal office with a good outcome regarding VC's security and functionality.
In the end, it's the same with every kind of encryption: if encrypted data gets damaged, it can become quite a hassle to get data back. This is not a software specific issue.
Finally, I looked up a few issues regarding VeraCrypt and Mac filesystem. All issues I found with a quick search were produced by either OS issues, other software blocking VeraCrypt driver calls or inappropriate handling of the mounted volumes by their users. But I will not deny what there still could be issues, caused by VeraCrypt itself. That's still the nature of software, created by humans.
Anyway, to sum it up, I'm glad that you got your data back.
Greets