Thanks for your answers Allen and Shane.

Meanwhile I did some more digging into this myself, and I found out that the problem is that KiXtart v4.67 cannot handle integers larger than 2,147,483,647.
And 2,147,483,647 KB is 2 TB.
The value has to be between ‑2,147,483,648 and 2,147,483,647
This is a 32bit restriction.
See: Wikipedia: 2,147,483,647
When an integer value becomes larger than 2,147,483,647 it will wrap and start from ~~zero~~ ‑2,147,483,648 again.

At first I tried to solve it with the GetDiskSpace function by taking this restriction into account: to get the correct value I tried to first converting the result from KB to MB (dividing by 1024), and then add a fixed number.

This works for drives up to 4TB:

Code:

$DriveSize = INT(CREATEOBJECT("Scripting.FileSystemObject").GetDrive($Drive).TotalSize/1048576)
$DriveSpace = INT(GETDISKSPACE($Drive+':\')/1024)
IF $DriveSpace < 0                ; Drivespace is larger then 2TB
	$TBsize = INT($DriveSize/1048576)
	$DriveSpace = INT(((GETDISKSPACE($Drive+':\')-2147483648)/1024)+($TBsize-1)*1048576)
ENDIF
$DrivePrSpc = INT(100*$DriveSpace/$DriveSize)

This returns the DriveSize and DriveSpace in MB and the DriveSpace in % of DriveSize.
But that does not work reliably for drives larger then 4TB because it is not sure how much has to be added to correct the value: this depends on the true amount of rounded available TB’s and the total drive size.

So this is how I solved it in the end:

Code:

$DriveSpace = INT(CREATEOBJECT("Scripting.FileSystemObject").GetDrive($Drive).AvailableSpace/1048576)

This returns the correct available space of the drive $Drive in MB.

But it would be great if Ruud would release a new version that copes with this problem.
Probably we need a 64bit version?