Thank you for your feedback.
The VeraCrypt hang you are encountering is not a real hang but it is rather due to the extreme slowness of one step of the change password operation : volume header wipe.
Actually, VeraCrypt inherits a logic from TrueCrypt where a new volume header is derived from the new password
(every time with a new random salt, 256 for normal header and 256 for backup header) and it is written each time to the container. This was done this way to ensure the previous volume header is completely wiped from the hard driver
and that it can't be recovered with such sophisticated techniques as magnetic force microscopy or magnetic force scanning tunneling microscopy.
Since VeraCrypt implement a more secure key derivation, deriving a new header 512 times takes indeed too much time (more than 2 hours). This is of course not always an acceptable delay.
Wiping the previous header objective is to protect against an attacker who compromized the previous password and who can probe the physical sectors of the hard drive. It has no meaning if the volume container is copied elsewhere or synchronized on the cloud
Recent studies have show that a single wipe pass is sufficient to make the original data irretrievable. Moreover, in the case of large capacity hard drives, there is no guaranty that overwriting a data will use the same physical sectors as the drive embedded
controller optimizes write operations by distributing data over new sectors.
In light of this, the use of 256 passes for rewriting each header is an overkill and as such we will change the default number of passes to 3. We will also add a configuration option to the change password dialog in order to make it possible to choose the desired
number of iterations for those who want to stick with the current implementation.
Some references :