Locking Memory to Prevent Paging Sensitive Data

You can prevent data from being written to the page file by locking it in memory. However, doing so is actively discouraged because locking memory can prevent the operating system from performing some memory management tasks effectively. Therefore, you should lock memory (by using functions like AllocateUserPhysicalPages and VirtualLock) with caution and only do so when dealing with highly sensitive data. Be aware that locking memory does not prevent the memory from being written to a hibernate file or to a crash dump file, nor does it prevent an attacker from attaching a debugger to the process and reading data out of the application address space.

More Information about VirtualLock

Using the VirtualLock API on Windows NT 4 and later, applications can lock specific virtual addresses into their working sets. Addresses locked in this fashion will not be paged out upon return from this function. This also has the side effect of preventing the process from being entirely swapped out (even when all its threads are in usermode waits) because the process can only be entirely swapped out after its entire working set has been emptied.

There are some caveats, however.

This is typically used by the application programmer in an attempt to increase performance by keeping desired addresses resident in main memory. However, the programmer should carefully benchmark the application in many different scenarios before and after this type of change because locking pages in this manner is charged against the entire physical memory of the machine. As a result, other operations requiring memory may fail, even some operations issued by the locking application! Instead, if the application pages are frequently referenced, they will typically remain resident anyway because the operating system always tries to trim inactive pages first. Active pages are only trimmed if the system has no other recourse.

Another reason application programmers sometimes resort to this function is to prevent memory containing sensitive data from being written to disk. This is different from keeping memory resident (that is, a page can be written to disk and still remain resident). Here are the issues involved:

The application must be sure to lock the virtual addresses before putting any sensitive data in it because the address may get trimmed and written to disk just prior to being locked, in which case the data at that point in time will be written to disk.
If the virtual addresses being locked are part of a shared section (pagefile-backed or file-backed), and another process modifies the pages and that other process doesn't also have the pages locked, then the shared pages may be written to disk even though the first process locked them correctly. Basically, it boils down to this critical point: if you don't want pages in your process written to disk, then all processes that can access that memory must also lock it properly.