IoCancelirp does not cancel the IRP in AMD64bit HP machine

NTDEV
1

Hi,

I am developing NDIS driver for Windows7.

I am facing some problem with IoCancelIrp API.
Some times Even though IRP is cancel bit is set, the IoCompletionRoutine set is not called, and I end up in waiting infinetley for the IRP cancel indication.

I directly send my IRP to USB class driver.
The same code works fine in 32 bit processor.
The same driver also works well with AMD64 bit processor, IBM machine.

Here is the code sniplet.

//completion routine…
NTSTATUS USBD_CompletionRoutine(PDEVCIE_OBJECt pd, PIRP pIrp, PVOID pEvent)
{
KeSetEvent((PKEVENT)pEvent, IO_NO_INCREMENT, FALSE);
return STATUS_MORE_PROCESSING_REQUIRED;
}

…
…
…
IoSetCompletionRoutine(irp, USBD_CompletionRoutine, (PVOID)&event, TRUE, TRUE,TRUE);

ntStatus = IoCallDriver(pDev->StackDevObj, irp);

if(ntStatus == STATUS_PENDING)
{
delay.QuadPart = -(15*1000*1000);
ntStatus = KeWaitForSingleObject(&event, Executive,KernelMode, FALSE, &delayValue);
if(ntStatus == STATUS_TIMEOUT)
{
IoCancelIrp(irp);

//Do not include any time out for the cancel IRP, as uncancelled presence of IRP in lower level driver might cause a big problem
KeWaitForSingleObject(&event, Executive,KernelMode, FALSE, NULL);

}

}

…
…

I am unable to find the reason for this behaviour.

Please help me to analyse…

2

What does windbg !irp say about your stuck irp?

On Monday, May 25, 2009, wrote:
> Hi,
>
> I am developing NDIS driver for Windows7.
>
> I am facing some problem with IoCancelIrp API.
> Some times Even though IRP is cancel bit is set, the IoCompletionRoutine set is not called, and I end up in waiting infinetley for the IRP cancel indication.
>
> I directly send my IRP to USB class driver.
> The same code works fine in 32 bit processor.
> The same driver also works well with AMD64 bit processor, IBM machine.
>
> Here is the code sniplet.
>
> //completion routine…
> NTSTATUS USBD_CompletionRoutine(PDEVCIE_OBJECt pd, PIRP pIrp, PVOID pEvent)
> {
> ? KeSetEvent((PKEVENT)pEvent, IO_NO_INCREMENT, FALSE);
> ? return STATUS_MORE_PROCESSING_REQUIRED;
> }
>
> …
> …
> …
> IoSetCompletionRoutine(irp, USBD_CompletionRoutine, (PVOID)&event, TRUE, TRUE,TRUE);
>
> ntStatus = IoCallDriver(pDev->StackDevObj, irp);
>
> if(ntStatus == STATUS_PENDING)
> {
> ?delay.QuadPart = -(1510001000);
> ?ntStatus = KeWaitForSingleObject(&event, Executive,KernelMode, FALSE, &delayValue);
> ?if(ntStatus == STATUS_TIMEOUT)
> ? {
> ? ? ?IoCancelIrp(irp);
>
> ? ?//Do not include any time out for the cancel IRP, as uncancelled presence of IRP in lower level ? driver might cause a big problem
> ? ? ?KeWaitForSingleObject(&event, Executive,KernelMode, FALSE, NULL);
>
> ? }
>
> }
>
> …
> …
>
> I am unable to find the reason for this behaviour.
>
> Please help me to analyse…
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

3

From:
> I am facing some problem with IoCancelIrp API.
> Some times Even though IRP is cancel bit is set, the IoCompletionRoutine
> set is not called, and I end up in waiting infinetley for the IRP cancel
> indication.

Is it possible that you created your event as a SynchronizationEvent instead
of a NotificationEvent? If so, there may be a subtle bug whereby the first
call to KeWaitForSingleObject is resetting the event AND returning
STATUS_TIMEOUT. (I’m assuming you created your IRP with
IoBuildDeviceIoControlRequest, because the rest of your code matches a
pattern I thoroughly thought out and described on pp. 282-84 of my WDM
book.)

Walter Oney
Consulting and Training
www.oneysoft.com

4

Vishal Kumar wrote:

I directly send my IRP to USB class driver. The same code works
fine in 32 bit processor. The same driver also works well with
AMD64 bit processor, IBM machine.

Why are you trying to cancel your URBs in the first place? Note that if your device has gone totally whacko and you are trying to recover, the host controller might get hung and won’t respond to your cancel anyway (seen this many times…)

Note that you say it’s working on one 64-bit machine and not another, they may have different host controllers, one more robust than another…