Delphi errors on Remote Desktop Server

Question

Are there any logging/trace tools that I can enable for a Delphi-based EXE without having access to the Delphi code, just the compiled EXE and related DLLs?

Here is why I need it: some users of our Windows 2012 Remote Desktop Server (previously called Terminal Server) encounter C0000006 External Exception errors periodically, but only for our third-party Delphi-based applications that are accessed from a shared location on the network (i.e. not local to the RDS server). Local PC users in the office accessing the same files the same way do not have the problem. RDS users do not experience the problem if the EXEs are copied to the RDS server; that, however, is just a test, and not the solution, due to some constraints of the application.

Here is the kicker: it happens only with RDS clients running on the Mac (about six users), not Windows RDS clients (about 15 users).

I already posted a detailed but as-yet unanswered question on the MS terminal server forum. My research indicates that this behaviour is nothing new.

1. Windows 2000 had a fix for a problem with the same symptom that was related to Windows being confused regarding which client session had a particular program open.
2. Even as recently as Windows 2008, there are Delphi-specific network access issues on RDS related to the way it loads portions of EXEs/DLLs on demand, rather than one time when opening the application. I infer that, while the symptoms are the same, the underlying cause must be somewhat different.

So, while I await the prognosis of the third-party developers, I am trying to find out if there is any way I can set up a trace of activity, either Delphi-specific or perhaps even network-related, that can tell me the moments when a particular session accesses a particular network file. This, at least, could possibly help me identify events that correlate with the moments the users experience the errors.

Answer 1

You don't need any program specific logging because the error is more fundamental, and unrelated to any programming language. That is a native API error code, an NTSTATUS value, specifically STATUS_IN_PAGE_ERROR.

These are low-level errors indicating a fundamental problem with the virtual memory system. Virtual memory pages can be stored on disk when physical memory is not available. For executable modules, if the system knows that a page is held on disk, and that page can be discarded, the system will do so knowing that the page can be retrieved later. Sometimes the page has never even been loaded into memory. Executable modules are paged in on demand.

The STATUS_IN_PAGE_ERROR error indicates that the virtual memory system failed to bring a page in to memory. It's rare for that to fail when the executable file is local. Less rare when the executable file is remote.

The standard way to deal with this is to add the IMAGE_FILE_NET_RUN_FROM_SWAP PE flag to any modules that live remotely. What happens then is that the loader first copies the entire file to swap, held locally, and then loads the executable from there. Because the swap file is local it is less like to have page in faults. You could apply the PE flag yourself to trial this. It seems likely to work because you already commented that the problem is resolved when the files are copied to be local.

It's plausible that there are system wide policies to make this happen for all remote executables.