Max and Doron,
Unfortunately, it looks like the problem is not related to UserEvent, at least in the OP’s words - according to him, his completion routine just does not get invoked. First I thought that Irp->UserEvent is the culprit here, but, according to the OP, this is not the case…
In other words, it is just incredible…
Anton Bassov
I never said the stuck irp was related to using UserEvent. access to
this field is inconsequential to its completion back to the driver.
What does !irp say? Have you tried canceling the irp?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, June 27, 2007 1:53 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Why system lower driver never finish the IRP
sometimes?
Max and Doron,
Unfortunately, it looks like the problem is not related to UserEvent, at
least in the OP’s words - according to him, his completion routine just
does not get invoked. First I thought that Irp->UserEvent is the culprit
here, but, according to the OP, this is not the case…
In other words, it is just incredible…
Anton Bassov
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks a lot everyone.
I discard Irp->UserEvent, use the ‘Context’ pass the event to IoCompletion routine, but all the things goes like before.
Doron Holan, i can’t understand the following:
->This is a driver allocated IRP, you do not want to let the io manager
complete it for you, it will bugcheck when it tries to a queue an apc to
the owning thread.
Yes, i allocate the irp, what i want is that the IO managere let the lower drivers call my IoCompletion routine i have set for the irp, and it did that in most cases. All the things that frustrate me much is that the IoCompletion routine sometimes never been invoked. Of course, we all know the IoCompletion callback is the system mechanism. It should happen that the IoCompletion routine never been invoked. My driver corrupt the memory lead the IoCompletion routine not been called? I don’t think so, because i never encounter bugcheck, if it is the case, my driver should crash system sometimes, isn’t it?
－>Have you tried canceling the irp?
I will try, after all, this is a good idea, but I am afraid canceling will not be successful in the case that the irp was pending and never been completed.
I type the wrong text. the IoCompletion callback is the system mechanism. It should never happen that the IoCompletion routine never been invoked, doesn’t it?
Oh, guys, i found a problem to cancel the irp. That’s when to call the IoCancelIrp()? The perfect way is when the time that the irp pended exceeds certain time(for example, 10 seconds), we call IoCancelIrp to cancel the irp, how to do this? Does it need a timer again? If it does, then i feel it is a waste action to set the timer every time for each irp, because most of the IRP are completed by the lower driver quickly, though IoCallDriver return STATUS_PENDING, IoCompletion routine gets invoked very quickly.
If this is your own IRP that you are waiting synchronously for its
completion, then set the wait timer for 10 seconds and if you return
with a timeout cancel the IRP and wait (forever this time) again.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of activism@163.com
Sent: Thursday, June 28, 2007 5:16 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Why system lower driver never finish the IRP
sometimes?
Oh, guys, i found a problem to cancel the irp. That’s when to call the
IoCancelIrp()? The perfect way is when the time that the irp pended
exceeds certain time(for example, 10 seconds), we call IoCancelIrp to
cancel the irp, how to do this? Does it need a timer again? If it does,
then i feel it is a waste action to set the timer every time for each
irp, because most of the IRP are completed by the lower driver quickly,
though IoCallDriver return STATUS_PENDING, IoCompletion routine gets
invoked very quickly.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
From the article, it seems that the canceling irp usually is used in the termination of a thread which executes an asnychronus IO request. In order to cope an occasional stick irp which we don’t know why, we use the canceling irp, is that a proper way? To say the least, it is proper to do this, then who can give me piece of sample code about canceling? To be a joke, I am sensitive in using the DPC object, timer object or workitem, for the stick irp is allocated and pass to lower with the *assitant*( may be they are the mudereres, though there is no proof) of these objects.
Ma LiJun wrote:
To be a joke, I am sensitive in using the DPC object, timer
object or workitem, for the stick irp is allocated and pass
to lower with the *assitant*( may be they are the
mudereres, though there is no proof) of these objects.
What?
Hi, Chris Aseltine, following is the stuck irp’ executed environment:
when received IRP_MN_START_DEVICE,
1 send the request to lower and wait to be finished successfully
2 then initialize the DPC(set the CustomDpc routine) and timer,then set the
timer(5 seconds interval)
In the CustomDpc routine, i allocate a workitem and queue it.
In the workitem routine, i did the following:
1 allocate an irp ,
2 initialize it(note:i have set srb.TimeOutValue = 10)
3 set iocompletion routine for the irp
4 call the next lower driver.The code piece like the following:
status = IoCallDriver(fdoExtension->CommonExtension.LowerDeviceObject, irp);
if (status == STATUS_PENDING)
{
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_ERROR_LEVEL,“***********
Wait IRP to finished \n”);
status = KeWaitForSingleObject(&event, Executive, KernelMode, FALSE,
NULL);//&WaitInterval);
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_ERROR_LEVEL,“*********** Wait IRP
success\n”);
status = ioStatus.Status;
}
The stick irp is allocated and pass to the lower in the way about( through a work item), i suspect the reason that the irp is pended and never been completed related to those object more or less. In fact, i allocate and pass the irps to lower driver many times in my driver, but they are not use the way above, i means they aren’t allocated and pass to the lower in a system work thread environment, and they never been stuck.
Hi, Chris Aseltine, following is the stuck irp’ executed environment:
when received IRP_MN_START_DEVICE,
1 send the request to lower and wait to be finished successfully
2 then initialize the DPC(set the CustomDpc routine) and timer,then set the
timer(5 seconds interval)
In the CustomDpc routine, i allocate a workitem and queue it.
In the workitem routine, i did the following:
1 allocate an irp ,
2 initialize it(note:i have set srb.TimeOutValue = 10)
3 set iocompletion routine for the irp
4 call the next lower driver.The code piece like the following:
status = IoCallDriver(fdoExtension->CommonExtension.LowerDeviceObject, irp);
if (status == STATUS_PENDING)
{
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_ERROR_LEVEL,“***********
Wait IRP to finished \n”);
status = KeWaitForSingleObject(&event, Executive, KernelMode, FALSE,
NULL);//&WaitInterval);
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_ERROR_LEVEL,“*********** Wait IRP
success\n”);
status = ioStatus.Status;
}
The stick irp is allocated and pass to the lower in the way about( through a work item), i suspect the reason that the irp is pended and never been completed related to those objects more or less. In fact, i allocate and pass the irps to lower driver many times in my driver, but they are not use the way above, i means they aren’t allocated and pass to the lower in a system work thread environment like the stuck irp, and they never been stuck.