Error windows when entering the password to mount a volume automatically detected

[leo5678]

Expected behavior

A the start of the computer, veracrypt asks for the password of a volume automatically detected (volume identified as favorites) and everything goes smoothly

Observed behavior

After unlocking Windows after a boot, when I enter my password to mount a VeraCrypt volume (automatic option activated), a Windows application error dialog appears:

Windows - Fehler in Anwendung
Die Anweisung in 0x00007FFxxxxxxxxx verwies auf Arbeitsspeicher bei 0x0000000000000028. Der Vorgang read konnte im Arbeitsspeicher nicht durchgeführt werden.

Translation: "The instruction at 0x00007FFxxxxxxxxx referenced memory at 0x0000000000000028. The memory could not be read."

The memory address changes between occurrences due to ASLR, but the offset remains consistent at +0x2B48A from VeraCrypt.exe base address. The target address is always 0x28, suggesting a null pointer dereference with a struct offset.

This doesn't prevent from acceding the volume, which seems to be mounted correctly but the appearence of an error windows is annoying

Steps to reproduce

1. Have VeraCrypt installed and configured to mount a volume automatically when the computer starts
2. Boot or reboot windows
3. Enter the VeraCrypt password to mount the volume
4. The error dialog appears

Your Environment

Please tell us more about your environment

VeraCrypt version: 1.26.24
OS: Windows 11 24H2 (Build 26100.7840)
type 64 bit

[Bcuzeau]

I have the same error when mounting fro a removable drive, appeared after switching from win10 to Win 11.
Luckily enough the drive is mounted and works...

[idrassi]

Thanks for the detailed report.

I investigated the crash offset from the Event Viewer entry. In the official 1.26.24 x64 binary, the reported instruction offset maps to a std::wstring copy inside the auto-generated FavoriteVolume copy constructor (the read at 0x28 matches reading the second wstring member from a FavoriteVolume* whose backing memory has been freed/zeroed).
I traced the favorite-mount paths and found two related issues that can produce this kind of dangling/invalid FavoriteVolume: a background-thread path that captured a raw pointer into the global favorites vector, and a mount-on-arrival cleanup path with an uninitialized iterator-control variable plus an unconditional push of FavoriteVolume copies even when mount failed.

I have implemented a fix that:

• makes the background favorite-mount thread own its own copy of the selected favorite volume
• avoids unnecessary FavoriteVolume copies in the relevant favorites paths
• fixes mount-on-arrival iteration so it updates the actual list entries instead of temporary copies
• only tracks a mount-on-arrival favorite as still connected after a successful mount
• ensures the mount-in-progress state is always cleared on exit paths

This should address the crash pattern described here, but since the original report did not include a crash dump/call stack, I would like to have it confirmed against a test build.

I'm working towards the next release and I will share when a beta build is available.