INFO: Cautions on Using METHOD_NEITHER IOCTL

• Microsoft Win32 Device Development Kit (DDK) for Windows NT, versions 3.5, 3.51

SUMMARY

This articles discusses three caveats to keep in mind if you create custom IOCTL code for use with a driver so that the driver accesses memory allocated by an application.

MORE INFORMATION

First, in order for this operation to succeed, the driver may only get access to the memory if it is a highest level driver whose DispatchDeviceControl routine is run in the context of the thread manufactured to request this operation. A driver's StartIo, DPC, ISR, or APC routine cannot be guaranteed of this as these routines are run in an arbitrary thread context.

Second, any access to this buffer must be wrapped in an appropriate exception handler. The buffer must be probed by calling MmProbeAndLockPages. Be careful when performing operations on this buffer. Access could also be obtained by wrapping access to the buffer in an appropriate exception handler, locking the pages, and then mapping the locked pages. With this alternative method, caution must still be used when performing operations on the buffer. Problems can occur when the application that owns this buffer changes the access mode for the memory or attempts to deallocate the memory while the driver attempts to read or write to it.

Third, caution must be exercised as there is no way to synchronize access to this memory between the driver and the application. Applications should NEVER attempt to share memory by using a DeviceIoControl call. As well, an application should NEVER attempt to read or write to the buffer simultaneous with a driver.

In conclusion, while it is possible to share memory between an application and a driver, the aforementioned precautions must be observed. Setting up sharing of memory should be done using a DeviceIoControl (for example, by mapping a region of memory into the applications address space), and alternatives should be exercised if feasible.