Problem using DirSize()

[seckner]

I'm running WB 2017B on a 64 bit Windows 10 v1709 laptop. DirSize() is giving me fits and I'm really not sure why. The failing line is Size = DirSize( "\\fileserver\art\", 0, 0 ) and it returns a size of 2073302495935.000000. It does return a correct value BUT here's the part I can't quite understand:

If this is compile and run as an exe or in Winbatch Studio as a 32 bit program, it succeeds.
If this is compile and run as an exe or in Winbatch Studio as a 64 bit program, it crashes and produces the very unhelpful error I've attached a picture of. 
If I run it as a 64 bit exe and set compatibility to Windows 8, it succeeds.

To ensure this was the line that's failing I wrapped it in my logging, so three lines would be:
"Starting DirSize" 
Size = DirSize( "\\fileserver\art\", 0, 0 ) 
"Ending DirSize".
If I open the log file after a crash the last logged item is "Starting DirSize". Looking at the Windows Event log for applications is this:

Faulting application name: winbatch.exe, version: 2017.2.0.0, time stamp: 0x58ed0bed
Faulting module name: ntdll.dll, version: 10.0.16299.64, time stamp: 0x493793ea
Exception code: 0xc0000374
Fault offset: 0x00000000000f87bb
Faulting process id: 0xb08
Faulting application start time: 0x01d380bf6f331cb5
Faulting application path: C:\Program Files\WinBatch\System\winbatch.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: a7eb870b-3cb6-4542-a43c-109986d36091
Faulting package full name:
Faulting package-relative application ID:

[td]

Thanks for reporting the problem. 

We tried the 64-bit WinBatch DirSize function on a Windows 10 version 1709 64-bit system pointing it at a share on another Windows 10 system and could not reproduce the problem.  The share contained about 7 GB of data with the directory nesting being at max about 10 directories deep on this share.

The error you are receiving is a heap corruption error.  This error usually occurs when a process attempts to read from or write to unallocated process memory.  It is occurring in a system dll (ntdll.dll) function indirectly called by the WIL interpreter dll and not in the WinBatch interpreter dll or in a ntdll.dll function directly called by the WIL interpreter.   

The fact that you do not see the problem when using 32-bit WinBatch eliminates most of the usual suspected causes of a heap corruption bug.  This is in part because the implementation of the 32-bit and 64-bit versions of the WIL function are identical.  The only difference between the two is the output produced by their respective native instruction set generating compilers.

Given what is known about the stability of Windows 10 version 1709, the information stated above, and few other bits of evidence; the best guess is that you have encountered another Windows 10 version 1709 bug.  This is not an attempt to kick the can down the road to avoid having to do anything or to protect our sensitive egos.  Simply put, it is in our best interest to identify and fix any WinBatch bugs as quickly as we can so we keep our users. 

One thing you could try to help confirm that this is a Windows problem is to point the 64-bit function at the same share on a system not running Windows 10 version 1709 and report back the result.

The only workaround we can think of besides sticking to 32-bit WinBatch is to use the FAF extender to implement your own version the DirSize function.  The downside is the role-your-own version would likely be much slower.

We will continue to monitor this problem and please report back any additional information you find.

[seckner]

Thanks for looking into this. The directory that it's pointed at is several hundred gig in size, I'm sorry for not including that. I won't have access to a version 1703 laptop until next week so I set it up on Tuesday and report back any findings.

Happy New Year to everyone, especially to the crew that are keeping WB alive and thriving. I've been a user of WB since 1999 and many of you are companions I've never met. Chuck, Stan, JT, Snow, KD and Tony, I've come to appreciate each of you. And the one's that we've lost from the community along the way, Guido, Jay, Marty, Detlev, Les and others. Hands down, to the the gold standard of a support community, Happy New Years to all!

[stanl]

Happy New Year to everyone, especially to the crew that are keeping WB alive and thriving. I've been a user of WB since 1999 and many of you are companions I've never met. Chuck, Stan, JT, Snow, KD and Tony, I've come to appreciate each of you. And the one's that we've lost from the community along the way, Guido, Jay, Marty, Detlev, Les and others. Hands down, to the the gold standard of a support community, Happy New Years to all!

Appreciate that. And let us not forget IfICantByte and some remarkable contributions.

[td]

Thanks for looking into this. The directory that it's pointed at is several hundred gig in size, I'm sorry for not including that. I won't have access to a version 1703 laptop until next week so I set it up on Tuesday and report back any findings.

Happy New Year to everyone, especially to the crew that are keeping WB alive and thriving. I've been a user of WB since 1999 and many of you are companions I've never met. Chuck, Stan, JT, Snow, KD and Tony, I've come to appreciate each of you. And the one's that we've lost from the community along the way, Guido, Jay, Marty, Detlev, Les and others. Hands down, to the the gold standard of a support community, Happy New Years to all!

We did some additional testing on Windows 10 1709 against a 318 GB share and 50 GB share and no joy.  Both 32-bit and 64-bit WinBatch functioned without error.