Microsoft KB Archive/290501

{|
 * width="100%"|

PRB: Invalid Page Fault Occurs When Calling VirtualProtect

 * }

Q290501

-

The information in this article applies to:


 * Microsoft Windows Millennium Edition

-

SYMPTOMS
If you use the VirtualProtect API to change the protections on system DLL code in memory, an &quot;invalid page fault (trap 14)&quot; may occur when another thread attempts to execute code in the system DLL.

CAUSE
In this scenario, VirtualProtect causes the virtual pages for the system DLL to be briefly decommitted and remapped to new pages. If another thread attempts to execute this code while it is decommitted, an invalid page fault will result.

RESOLUTION
The most reliable way to work around this problem is to avoid using VirtualProtect to change the protections on system DLL code in memory.

If this is not possible, you may be able to work around this problem by one of the following methods (listed approximately in order of expected effectiveness). However, these workarounds may not be entirely effective or safe, and are offered only as suggestions that should be thoroughly tested before being implemented.


 * 1) Privatize the module during initialization by write-enabling a page (any page) and then reprotecting it. Later, when VirtualProtect is called, the module will have already been privatized so the race condition is not encountered.
 * 2) Suspend all other threads in the process (if possible) before calling VirtualProtect, and then resume them after VirtualProtect completes.
 * 3) Temporarily increase the priority of the thread that is calling VirtualProtect before the call, and reduce the priority after VirtualProtect finishes.

STATUS
Microsoft has confirmed this to be a problem in the Microsoft products that are listed at the beginning of this article.