'largest free block' reported value looks wrong

[Brian THOMAS]

Some of our customers have sent us madExcept bugreport files whose contents look suspicious to me:

Code: Select all

date/time          : 2019-11-11, 14:56:39, 572ms
computer name      : PC0290
user name          : sla
registered owner   : Authorised User
operating system   : Windows 10 x64 build 16299
system language    : English
system up time     : 5 hours 14 minutes
program up time    : 2 hours 42 minutes
processors         : 4x Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
physical memory    : 2149/8079 MB (free/total)
free disk space    : (C:) 49.26 GB
display mode       : 1600x900, 32 bit
process id         : $f3c
allocated memory   : 662.28 MB
largest free block : 128645.68 GB
executable         : OUTLOOK.EXE
current module     : KapprisLibrary.dll
module date/time   : 2019-05-09 09:20
version            : 2.3.1.13276
compiled with      : Delphi 10.2 Tokyo
madExcept version  : 4.0.19

There's no way that largest free block value can be correct is there? Is Windows itself misreporting? Or is there an error in madExcept? Or some other explanation?

[iconic]

We will look into this without a doubt. Those numbers in (GBs) add up to several Terabytes which is completely incorrect, in this use case it's over 128 TB.

--Iconic

[madshi]

Wow, that looks weird!!

I've added a little code tweak to hopefully fix this, although I'm not fully sure how this would happen exactly. I assume that negative numbers are involved somehow.