madshi.net

Posted: **Wed Feb 05, 2020 3:35 pm**

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

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?

Posted: **Fri Feb 07, 2020 11:33 pm**

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

Posted: **Sat Feb 08, 2020 9:00 am**

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.

madshi.net

'largest free block' reported value looks wrong

'largest free block' reported value looks wrong

Re: 'largest free block' reported value looks wrong

Re: 'largest free block' reported value looks wrong