G

It's a relief to see a solution coming into place for this. Vadim/botty's post from 2021-10-22 that RadarNyan mentioned pointed to useful info as did mine from 2021-09-09 which specifically mentioned attestation signing being a possible option for VeraCrypt's non-PnP driver. I won't hold my breath as far as full support for XP/2003 returning as well since there will be no dual signature in future releases. However, if unsigned releases on a limited basis such as once per year could be considered...

I'm not particularly familiar with driver programming/signing and tried to learn what is going on from here: https://www.osr.com/blog/2021/04/08/lost-cause-no-driver-updates-allowed-except-for-win-10/ They seem to indicate that WHQL and/or Attestation Signing may be options for Windows 7, especially for non-PnP / non-hardware drivers like the one included with VeraCrypt. Not sure if that helps with Vista or XP/2003 at all though. My personal experience with XP/2003 is that system drivers don't seem...

DDD: Your user-initiated crashes should generate a memory.dmp crash dump file. Have you sent a crash dump to Mounir for analysis yet? I've been plagued by the exact problem described by Rivaro Zenner for a long time, but with a competing "Crypt" product, not VeraCrypt. I very recently began testing if VeraCrypt is more reliable, so I don't have a crash dump of it failing that I can submit yet. Rivaro Zenner: Like DDD, I haven't found a way to mitigate the problem. I do always try to keep a VNC window...

DDD: Your user-initiated crashes should generate a memory.dmp crash dump file. Have you sent a crash dump to Mounir for analysis yet? I've been plagued by the exact problem described by Rivaro Zenner for a long time, but with a competing "Crypt" product, not VeraCrypt. I very recently began testing if VeraCrypt is more reliable, so I don't have a crash dump of it failing that I can submit yet. Rivaro Zenner: Like DDD, I haven't found a way to mitigate the problem. I do always try to keep a VNC window...

Apparently using /force when mounting from a command line does what I want. Using /force doesn't open the container file with exclusive access and allows shared reading. /force is much more commonly meant for forcing a container with open file(s) to dismount. The UI also includes forced dismount support. However, the UI seems to lack an equivalent of /force when mounting containers. For now I've set up a command line shortcut that includes /force and will use that until support for shared container...

Apparently using /force when mounting from a command line does what I want. Using /force doesn't open the container file with exclusive access and allows shared reading. /force is much more commonly meant for forcing a container with open file(s) to dismount, and the UI includes forced dismount support. The UI seems to lack an equivalent of /force when mounting containers. For now I've set up a command line shortcut that includes /force and will use that until support for shared container file access...

I would appreciate it if an option could be added to allow shared read access to container files that are currently mounted. This would eliminate problems with automated backups failing when for any reason a container is unexpectedly still mounted when the backup runs. I understand that there would be no guarantee that "shared" container backups would good/valid.