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

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: 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.