Microsoft KB Archive/282028

{|
 * width="100%"|

INFO: Kernel-Mode Device Drivers Cannot Call User-Mode When Handling File I/O

 * }

Q282028

-

The information in this article applies to:


 * Microsoft Windows 98 Driver Development Kit (DDK)
 * Microsoft Windows 95 Driver Development Kit (DDK)
 * Microsoft Windows ME Driver Development Kit (DDK)

-

SUMMARY
Microsoft Windows 95 or Windows 98 kernel-mode device drivers must never attempt to call a user-mode (ring 3) code when called in the context of a file I/O request. Doing so may cause a system deadlock to occur.

CAUSE
This behavior is a result of the Win32 architecture on Windows 95 and Windows 98.

WORKAROUND
There is no supported workaround for this behavior.

MORE INFORMATION
Kernel-mode drivers that handle file I/O requests must be able to complete these requests entirely within kernel-mode, and must not rely on user-mode code or specific threads being available to process the requests.

File I/O requests can pass through many types of kernel-mode device drivers on the Windows 95 and Windows 98 platform, including IOS drivers, local and network file system drivers, file system filter drivers, NDIS MAC drivers, network protocol drivers, modem and VCOMM drivers. None of these types of drivers should attempt to invoke ring-3 code to handle I/O requests if it is possible that the I/O request is the result of a file I/O operation.

The Windows 95 and Windows 98 system architecture employs two (2) synchronization objects to help deal with reentrancy issues. The two objects are:


 * Kernel32Mutex

-and-
 * Win16Mutex

The Win16Mutex object is used to prevent Win16 APIs from being reentered when being thunked to by Win32 APIs. For more information about Win16Mutex, see the following article in the Microsoft Knowledge Base:

"Q125867 Understanding Win16Mutex" Likewise, the Kernel32Mutex object is used to protect critical code paths in the Kernel32.dll file from being reentered. Both of these objects are internal to Windows and are inaccessible to other applications, DLLs, or drivers.

In some cases the Kernel32Mutex object is owned by the current thread for file I/O requests that originate from the Kernel32.dll file. If the Kernel32Mutex object is owned during a file I/O request, it prevents all other Win32 threads from running until the Kernel32Mutex object is released, which under these circumstances can only occur after the current file I/O operation completes.

The implication of the Kernel32 mutex being owned during a file I/O request is that any driver called within the context of a file I/O request must be able to complete the I/O request within an arbitrary thread context, and must not try to call a Win32 or Win16 application or DLL to help process the request. Doing so results in a deadlock.

It is also possible that the Win16Mutex object may be held during a file I/O request. If a kernel-mode driver calls into a user-mode application or DLL to handle a file I/O request at this time, and that application or DLL in turn calls a Windows API that attempts to take ownership of the Win16Mutex, a deadlock also occurs.