Occasionally we get reports of corrupted files from customers. These are rare and next-to-impossible to reproduce. When we log into the customers' machine remotely we find the file (usually an INI file) cannot be opened. Nor can the file be copied locally for analysis. Based on limited examples, these corrupted files have a size of "0kB" and can only be deleted. When this occurs, it appears to affect just one INI file out of dozens. The rest of the system is fine. Once the corrupted file is re-created, the system fully recovers.

We do not know how this happens and would like to reproduce and hopefully resolve the issue. Could be a Windows issue, a coding error, even a hardware issue related to powering down the machine unexpectedly. For test purposes, I've created a TXT file with random garbage as in:

// Delphi code, but applies to any language
procedure TfrmDiagnostics.CreateCorruptFile();
    fpDump: TextFile;
    nChar: Integer;
    RandSeed := (GetTickCount() mod 23);
    AssignFile(fpDump, 'C:\Corrupted.txt');
    for nChar:=1 to 100 do
        Write(fpDump, Chr(Random(250)));


This does generate a nicely mangled file, the first few bytes were: NREâA#»Bâ÷lÁb…ilL(‘—ØÏ­D YL&d.... But the file still opens in Notepad++ and a few other ASCII editors I tried.

Is it possible to create a genuinely "corrupt" file in Windows, one that Windows refuses to open? This possibly involves fiddling with the file-allocation table, but I doubt users have any access to the FAT (and it doesn't sound like a safe thing to do anyway).


The reason a file cannot be opened is not because the file is corrupt, but because there's a write-lock on the file.

This means that the network connection was cut when the file was open, and the server is keeping the lock active.

If you open Computer Management on the server, and unvold to Open Files, you should find references to those .ini files, with the ability to remove the lock, after which you can do anything to the file again.

To recreate such circumstance, create a file or open an existing file. Write to the file. While doing this, disconnect your pc from the network and then reconnect. The file will be corrupted and cannot be opened in a similar fashion as you experienced earlier.

Now, find out the reason why the network disconnects. For example, when working with Group Policies, note that group policies are refreshed about every 90 minutes. If you set the share to replace, it will delete the share, and recreate it every 90 minutes with a few minutes of random interval. If you are writing to a file at such time, the file could become corrupt.

| improve this answer | |
  • 2
    Worth pointing out that it's going to be the very definition of insanity if you attempt to cover every way a file is inaccessible or corrupted. So it's much easier (and arguably better) to have exception handling that through a notification informs the user the .ini file was recreated. If you are not talking about your company's application's .ini file then that's more complicated but also going to be impossible to cover every possible reason a .ini cannot be processed – Ramhound Sep 19 '17 at 9:33
  • Wouldn't a write lock also prevent the file from being deleted? – I say Reinstate Monica Sep 19 '17 at 9:34
  • Is there a way with some hacked code (any language) of creating a file locally (i.e. not over the network) with a write lock still active to try and reproduce this? – AlainD Sep 19 '17 at 9:43
  • @Twisty: That's correct. The file could not be opened by Windows but could be deleted. – AlainD Sep 19 '17 at 9:44
  • 1
    @Ramhound: Fair comment, I'll see what I can do to change the "check this file" code. Problem with this sort of issue is that the problem is so rare that you're never quite sure you've resolved the bug unless you can reproduce the problem before and after! – AlainD Sep 19 '17 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.