This article was previously published under Q199671
This article has been archived. It is offered "as is" and will no longer be updated.
If a 32-bit process attempts to load Wow32.dll, the operating system will also need to map Ntvdm.exe into the process address space. The Windows NT Virtual DOS computer is contained in Ntvdm.exe. This system component supports the running of 16-bit processes on Windows NT. If Ntvdm.exe cannot be mapped to its default base address of 0x0F000000, the operating system will attempt to relocate it. In Windows NT 4.0, this dynamic relocation fails on multiprocessor computers.
Under Windows NT 4.0, the system can dynamically relocate a file on a multiprocessor computer only if the file has been flagged as a DLL by linking it with the /DLL option. Ntvdm.exe is flagged as an EXE, rather than a DLL. As a result, an attempt to relocate Ntvdm.exe on a multiprocessor computer will fail.
Wow32.dll is a system library that supports the 32-bit side of the Win32 thunking layer. All of the functions exported from Wow32.dll are there to support generic thunks from 16-bit code to 32-bit code. These functions provide the necessary support for tasks such as making callbacks to 16-bit functions and translating 16-bit handles to 32-bit handles (and vice versa).
A call to LoadLibrary() on Wow32.dll (or any library that depends upon or loads Wow32.dll) causes Ntvdm.exe to be mapped into the caller's address space. Ideally, this situation should never arise because a 32-bit process should not load a 32-bit thunking DLL. A 32-bit thunking DLL should be loaded only by a 16-bit program via the LoadLibraryEx32W() API. The loading of a 32-bit thunking DLL into the address space of a 32-bit process is unsupported.
This behavior is by design.
If a call to LoadLibrary() fails on a multiprocessor system because the system could not relocate Ntvdm.exe, GetLastError() returns error code 998:
Invalid access to memory location (ERROR_NOACCESS)