Are there risks associated with IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP?

Question

I'm thinking of including the IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP and IMAGE_FILE_NET_RUN_FROM_SWAP PE flags to my executable.

The idea is to prevent occasional exceptions seen by clients who run the executable from the network, for example when network volumes fail to reconnect after sleep. Up to now we have always advised clients to run executables from locally connected volumes.

However, I don't know enough about virtual memory, the loader etc. to know what, if any, risks there are associated with using these PE flags.

For example, if I do this will more physical memory be consumed by my executable, especially if there are multiple instances of the executable running at the same time?

I'm sorry that I can't give more examples of potential risks, but that's the nature of my question. I have a feeling that there could be downsides to doing this but simply don't know what those downsides could be.

Answer 1

The PE loader works together vith the virtual memory manager. Simply put, your executable isn't so much loaded as demand-paged in. And, of course, demand-paged out. Since executables are locked and don't change, this works quite well. No swap is needed; RAM just contains the MRU parts.

The PE flags change this. If the conditions are satisfied, the executable isn't locked and might change/disappear. This means the VMM has to keep all its pages either in RAM or swap, even at startup. That's a lot of copying and RAM use, but as a result the loss of the network no longer causes page-in faults. And when RAM is low, pages can't be discarded but have to be saved to swap.

In particular, these flags work if and only if the conditions are satisfied. IMAGE_FILE_NET_RUN_FROM_SWAP does not affect apps that are run locally. So the only customers that pay the price in RAM/swap are those that choose to.