TDirectory - file lock out on Win 10 LTSC

[Roger Cigol 111]

VCL - RAD Studio 12.2 C++ Classic Compiler

 

I have a windows C++ (Classic compiler) VCL application that uses TDirectory::GetDirectories() and TDirectory::GetFiles() to get lists of files from the Windows OS file structure.

These files are then opened for read or write using stl ofstream and ifstream along with >> and << operators.

The same code has been in use on different instances of the application on different machines (including Win XP and Windows 7).

I have a new instance where the operating system is Windows 10 LTSC version 10.0.19044 build 19044. I have not run it on this version of windows before.

 

Problem; Directory and file lists, reading and writing work ok for a longish time (24 hours sometimes, 30 hours sometimes, 10 hours sometimes) and then

the calls to TDirectory::GetDirectories() and TDirectory::GetFiles() both return empty lists. Writing to a log file (with a fixed file name) also stops working at

this time. It's as if my application has been locked out of the file system somehow.

 

At this point it is possible to use File Explorer to see that there still are files and directories present. It is possible to open the files by other applications.

(some are plain text files and can be opened with notepad). The files are stored in a directory inside C:\Users\Public\Documents\ so

should be available to all applications all of the time.

 

I cannot offer a reproducible example - all my code works fine on my development machine (which is Windows 10 Pro build 19045.5371 22H2).

This is true if I run it under the IDE debugger or as a free standing exe.

 

I wonder if any of my fellow Delphi-Praxis colleagues might have any similar experiences or can offer some ideas of what I should try next ?

 

[Der schöne Günther 323]

10 minutes ago, Roger Cigol said:

Writing to a log file also stops working at this time. 

It's as if my application has been locked out of the file system somehow.

To me, it sounds more like your application has run out of resources. Not necessarily memory, but probably too many handles, like still opened files.

 

Check Windows Event Viewer for resource exhaustion events and other errors and warnings.

[Angus Robertson 590]

I wrote an open source component that indexes Windows directories and files recursively, written 20 years ago and used on every version of Windows and Delphi since, it just works, never fails. 

 

It currently builds a list of 1.2 million files on my c drive which it compares with the same number on a second drive, for backup on Windows 11.

 

Angus

 

[Roger Cigol 111]

29 minutes ago, Der schöne Günther said:

Check Windows Event Viewer for resource exhaustion events and other errors and warnings

@Der schöne GüntherMany thanks for this suggestion. Sadly (for me) I have already checked windows events - no sign of any problem error or warning messages.

[Kas Ob. 125]

Well, i don't have a idea about such case per se, but i witnessed many of these when i broke my OS kernel debugging and fooling around, so i have thoughts here

 

But first let me say what is different in LSTC from the normal, they are the same, except LTSC comes with slightly different default policies, policies that are not even listed in GP editor, some of them need to be added using ADMX files to be accessible, to have an idea look here these 

https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-storage

They mostly are documented though, yet many need to be added, so your OS might need some restoring its default.

 

That being said, now to what i think might be the cause, also while we shooting darts in the dark:

1) Storage handling layer and its drivers run in two layers User mode part and Kernel mode part, in some cases i caused a corruption in user mode, this triggered an exception, yet that exception wasn't critical to crash the system as it happened after returning form the kernel system calls (drivers), the exception marked the file handle as corrupted and left it in locked mode, or just the handle tables were faulty and the system couldn't add another handle or even try to read part of that table, sometimes many files locked, so no more file access with strange errors or simply freeze, yet the file(s) were accessible from from different processes, this due the user process sandboxing which start in kernel and extend to user mode.

2) LTSC does have delayed update policy, meaning fewer fixes will be pushed, so if there is a bug it could be simply fixed by update your LTSC to the latest and in case you can't then really running SFC 🙂 (as they always suggest) can help, the more info about running SFC is literally everywhere !

3) Your disk have a problem, i saw these on Server 2003, also have them on my old XP, the disk wasn't aligned, yes it is a thing and there is few tools to check disk aligning and fix it, 

https://superuser.com/questions/132296/how-to-check-the-partition-alignment-on-an-ssd-drive

Notice that searching the net now gives me only SSD result, but that is not the only case, it might happen with any disk type as it with mine, and also it increase the speed, and linger for trouble in accessing disks, which might be your case, 

One thing though don't use any non official application or method from any where on the net to align your disk, first check your disk manufacturer if they have such a tool, WD, Intel, Samsung ... they wither have tools or their software will check and prompt you to fix the alignment.

And with 3rdpary tools like the one mentioned here

https://www.diskpart.com/windows-10/ssd-alignment-windows-10-3889.html

It could be fine yet i wouldn't recommended it.

 

Hope that helps !

[Der schöne Günther 323]

Can't you just spin up a fresh VM with the same windows image and see if the problem persists?

[Remy Lebeau 1467]

4 hours ago, Roger Cigol said:

the calls to TDirectory::GetDirectories() and TDirectory::GetFiles() both return empty lists.

I don't trust the IOUtils unit. I feel it's functionality is bloated and error reporting is lacking/wonky. I prefer to stick with SysUtils::Find[First|Next]() or even ::Find[First|Next]File() directly. Have you tried that yet? Are there any error codes being reported when the problem happens?

 

Similarly with std::[i|o]fstream, they lack good error reporting, too. Do you get an error code from SysUtils::File[Create|Open]() or ::CreateFile()?