Create IRP

发布时间：2014-5-14 19:44
分类名称：Driver

IoBuildAsynchronousFsdRequest

builds an IRP on whose completion you don't plan to wait. This function and the next are appropriate for building only certain types of IRP.

IoBuildSynchronousFsdRequest

builds an IRP on whose completion you do plan to wait.

IoBuildDeviceIoControlRequest

builds a synchronous IRP_MJ_DE?VICE_CONTROL or IRP_MJ_INTERNAL_DEVICE_CONTROL request.

IoAllocateIrp

builds an asynchronous IRP of any type.

Synchronous IRPs

IoBuildSynchronousFsdRequest and IoBuildDeviceIoControlRequest create a so-called synchronous IRP.
The I/O Manager considers that a synchronous IRP belongs to the thread in whose context you create the IRP. This ownership concept has several consequences:

• If the owning thread terminates, the I/O Manager automatically cancels any pending synchronous IRPs that belong to that thread.
• Because the creating thread owns a synchronous IRP, you shouldn't create one in an arbitrary thread—you most emphatically do not want the I/O Manager to cancel the IRP because this thread happens to terminate.
• Following a call to IoCompleteRequest, the I/O Manager automatically cleans up a synchronous IRP and signals an event that you must provide.
• You must take care that the event object still exists at the time the I/O Manager signals it.

You must call these two functions at PASSIVE_LEVEL only. In particular, you must not be at APC_LEVEL (say, as a result of acquiring a fast mutex) because the I/O Manager won't then be able to deliver the special kernel asynchronous procedure call (APC) that does all the completion processing. In other words, you mustn't do this:

PIRP Irp = IoBuildSynchronousFsdRequest(...);
ExAcquireFastMutex(...);
NTSTATUS status = IoCallDriver(...);
if (status == STATUS_PENDING)
KeWaitForSingleObject(...); // <== don't do this
ExReleaseFastMutex(...);

KeWaitForSingleObject call will deadlock.

If you need to synchronize IRPs sent to another driver, consider the following alternatives:

• Use a regular kernel mutex instead of an executive fast mutex. The regular mutex leaves you at PASSIVE_LEVEL and doesn't inhibit special kernel APCs.
• Use KeEnterCriticalRegion to inhibit all but special kernel APCs, and then use ExAcquireFastMutexUnsafe to acquire the mutex. This technique won't work in the original release of Windows 98 because KeEnterCriticalRegion wasn't supported there. It will work on all later WDM platforms.
• Use an asynchronous IRP. Signal an event in the completion routine. Refer to IRP-handling scenario 8 at the end of this chapter for a code sample.

Asynchronous IRPs

IoBuildAsynchronousFsdRequest and IoAllocateIrp create an asynchronous IRP. Asynchronous IRPs don't belong to the creating thread, and the I/O Manager doesn't schedule an APC and doesn't clean up when the IRP completes. Consequently:

• When a thread terminates, the I/O Manager doesn't try to cancel any asynchronous IRPs that you happen to have created in that thread.
• It's OK to create asynchronous IRPs in an arbitrary or nonarbitrary thread.
• Because the I/O Manager doesn't do any cleanup when the IRP completes, you must provide a completion routine that will release buffers and call IoFreeIrp to release the memory used by the IRP.
• Because the I/O Manager doesn't automatically cancel asynchronous IRPs, you might have to provide code to do that when you no longer want the operation to occur.
• Because you don't wait for an asynchronous IRP to complete, you can create and send one at IRQL <= DISPATCH_LEVEL (assuming, that is, that the driver to which you send the IRP can handle the IRP at elevated IRQL—you must check the specifications for that driver!). Furthermore, it's OK to create and send an asynchronous IRP while owning a fast mutex.