>>>This could be the problem (network connection). Unfortunately, the customer won't let me connect to a user PC and read the Windows event viewer. I have to learn how to make the app deal with these type of errors on my own.
>>
>>Why don't you use a loader? Then the exe would be copied to the user's local drive, somewhere in %appdata%\dmitry\temp or some such folder, and any further decisions of M$ in regards of "this exe is staying open too long and holding up the handle... lemme close it for a while" would become irrelevant. No network, no problem.
>
>What loader would you recommend?

The general context of loaders we've used in the past require three parts on the network, and two parts on the local hard drive:

* Network:
1)  version.dbf
2)  launcher.exe
3)  program.exe specified in version.dbf

* Local drive:
1)  version.dbf
2)  program.exe

On the network, you have a structure that indicates the version number and the associated executable. On your local hard drive you have a copy of the version table, but it holds the version of the version last copied down.

If local drive doesn't have version.dbf, create a new one and copy down the newest program.exe.
If local drive does have version.dbf, compare the version to the one on the network. If it's the same, launch the local program.exe. If it's not the same, copy down the newest program.exe and update the local version.dbf to the newest version.

In this way, you always launch the network launcher.exe, which in turn always runs the c: program.exe.

It allows you to deploy new versions to one location, and they automatically propagate out. You can also add code to your main.prg which looks at the ASTACKINFO() to make sure you're running from launcher.exe, and are not launching directly from the .exe.