When trying to expand a non-system partition hosted Truecrypt volume that has been encrypted in-place, extcv fails to mount the volume with the newly written headers, see screenshot1. If you then try to mount the volume using Truecrypt you receive an error message that the process of encryption needs to be resumed, see sreenshot2.
Background:
When updating the Truecrypt header of the volume to be expanded, the volume size header field is updated according to the new size of the partition or file. However, at least in the case of partition hosted Truecrypt volume that have been encrypted in-place (have the flags bit 1 set), you also need to update the encrypted area lenght header field. If the volume size header field and the encrypted area lenght header field do not match for in-place encrypted partition hosted volumes, the mounting of the volume fails, see Truecrypt source code Driver/Ntvol.c at line 522 (for Truecrypt v7.1a).
Solution:
It should be save to let Truecrypt \"resume\" the encryption of the newly expanded volume and then expand the filesystem manually. [However, I did not test this (only a suggestion) and in my case (1.82TB) it would take a whole lot of time do to so.] Nevertheless, extcv displays an error message in this scenario, which should not happen. I recompiled extcv with a minor change: In ExpandVolume.c I use newDataAreaSize for cryptoInfo->EncryptedAreaLength.Value when the new volume header is prepared (line 800).
I am not sure if it is always okay to update the encrypted area length header field like this, but I guess it is since system encryption is not supported by extcv anyways (which might use this header field differently).
Screenshots of the error messages.