Unplug the usb power cause a system crash in winxp+sp2

I made a bda driver for our usb box. It seems working well until I
unplug the power wire when it running in winxp+sp2.(it saids that it
did not crash in win2k or winxp+sp1, so strange.)

In the read data routine, I insert the irp to a list and in the
complete routine I remove it from the list. Like this:
(I simply use the global variables.)
Insert:
--8<---------------cut here---------------start------------->8---
KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);

status = IoCallDriver(p_devobj, p_irp);
--8<---------------cut here---------------end--------------->8---
Removal:
--8<---------------cut here---------------start------------->8---
KeAcquireSpinLock(&g_ks_pl, &old_irql);

if (IsListEmpty(&g_irp_list))
{
KeReleaseSpinLock(&g_ks_pl, old_irql);
return FALSE;
}

RemoveHeadList(&g_irp_list);
KeReleaseSpinLock(&g_ks_pl, old_irql);
--8<---------------cut here---------------end--------------->8---

After I unplug the power of the usb, winxp+sp2 would crash in
usbport.sys. I commented out these codes, then unplug the power, no
crash.

I did not test the status of the irp, because I thought it was
useless. I simply insert the irp to the queue and remove it after it
completed.

Could some one tell me what's wrong with my code?
Advance thanks!

cristalink
Sun Aug 07 22:17:58 CDT 2005

How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry while
you hold p_irp in your list? You must remove an IRP from the Tail.Overlay
list before passing it to IoCallDriver. You should maintain the list by
other means.
--
http://www.cristalink.com


"WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
news:uiryhqgn0.fsf@hotmail.com.discuss...
>I made a bda driver for our usb box. It seems working well until I
> unplug the power wire when it running in winxp+sp2.(it saids that it
> did not crash in win2k or winxp+sp1, so strange.)
>
> In the read data routine, I insert the irp to a list and in the
> complete routine I remove it from the list. Like this:
> (I simply use the global variables.)
> Insert:
> --8<---------------cut here---------------start------------->8---
> KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
> InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
> KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);
>
> status = IoCallDriver(p_devobj, p_irp);
> --8<---------------cut here---------------end--------------->8---
> Removal:
> --8<---------------cut here---------------start------------->8---
> KeAcquireSpinLock(&g_ks_pl, &old_irql);
>
> if (IsListEmpty(&g_irp_list))
> {
> KeReleaseSpinLock(&g_ks_pl, old_irql);
> return FALSE;
> }
>
> RemoveHeadList(&g_irp_list);
> KeReleaseSpinLock(&g_ks_pl, old_irql);
> --8<---------------cut here---------------end--------------->8---
>
> After I unplug the power of the usb, winxp+sp2 would crash in
> usbport.sys. I commented out these codes, then unplug the power, no
> crash.
>
> I did not test the status of the irp, because I thought it was
> useless. I simply insert the irp to the queue and remove it after it
> completed.
>
> Could some one tell me what's wrong with my code?
> Advance thanks!
>

WilliamX
Sun Aug 07 23:19:43 CDT 2005

"cristalink" <cristalink@nospam.nospam> writes:

> How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry while

I think it is using it. It would cause something? I inserted the
Tail.Overlay.ListEntry to my list before call IoCallDriver, and
removed it from my list after it returned from lower. Mybe I don't
understand well how to use Tail.Overlay.ListEntry, please feel free to
point out my mistakes.

> you hold p_irp in your list? You must remove an IRP from the Tail.Overlay
> list before passing it to IoCallDriver. You should maintain the list by

Could you so kindly to show me some code about how to do it?

>
> other means.
> --
> http://www.cristalink.com
>
>
> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
> news:uiryhqgn0.fsf@hotmail.com.discuss...
>>I made a bda driver for our usb box. It seems working well until I
>> unplug the power wire when it running in winxp+sp2.(it saids that it
>> did not crash in win2k or winxp+sp1, so strange.)
>>
>> In the read data routine, I insert the irp to a list and in the
>> complete routine I remove it from the list. Like this:
>> (I simply use the global variables.)
>> Insert:
>> --8<---------------cut here---------------start------------->8---
>> KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
>> InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
>> KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);
>>
>> status = IoCallDriver(p_devobj, p_irp);
>> --8<---------------cut here---------------end--------------->8---
>> Removal:
>> --8<---------------cut here---------------start------------->8---
>> KeAcquireSpinLock(&g_ks_pl, &old_irql);
>>
>> if (IsListEmpty(&g_irp_list))
>> {
>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>> return FALSE;
>> }
>>
>> RemoveHeadList(&g_irp_list);
>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>> --8<---------------cut here---------------end--------------->8---
>>
>> After I unplug the power of the usb, winxp+sp2 would crash in
>> usbport.sys. I commented out these codes, then unplug the power, no
>> crash.
>>
>> I did not test the status of the irp, because I thought it was
>> useless. I simply insert the irp to the queue and remove it after it
>> completed.
>>
>> Could some one tell me what's wrong with my code?
>> Advance thanks!
>>

Alexander
Sun Aug 07 23:38:49 CDT 2005

From DDK documentation, topic: IRP

Tail.Overlay.ListEntry
If a driver manages its own internal queues of IRPs, it uses this field to
link one IRP to the next. These links can be used only while the driver is
holding the IRP in its queue or is processing the IRP.

"WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
news:uek95qcv4.fsf@hotmail.com.discuss...
> "cristalink" <cristalink@nospam.nospam> writes:
>
>> How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry while
>
> I think it is using it. It would cause something? I inserted the
> Tail.Overlay.ListEntry to my list before call IoCallDriver, and
> removed it from my list after it returned from lower. Mybe I don't
> understand well how to use Tail.Overlay.ListEntry, please feel free to
> point out my mistakes.
>

cristalink
Mon Aug 08 00:19:46 CDT 2005

The problem is, the lower drivers overwrites p_irp->Tail.Overlay.ListEntry,
thus screwing up your list. When you then remove p_irp from the list, you
are screwing up someone else's list.

The simplest alternative is to maintain a list of structures containing
pointers to IRPs. You'd need to allocate a structure per IRP, of course.
Another way could be using your IO_STACK_LOCATION as LIST_ENTRY. Sorry, I
don't have sample code at hand.

--
http://www.cristalink.com


"WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
news:uek95qcv4.fsf@hotmail.com.discuss...
> "cristalink" <cristalink@nospam.nospam> writes:
>
>> How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry while
>
> I think it is using it. It would cause something? I inserted the
> Tail.Overlay.ListEntry to my list before call IoCallDriver, and
> removed it from my list after it returned from lower. Mybe I don't
> understand well how to use Tail.Overlay.ListEntry, please feel free to
> point out my mistakes.
>
>> you hold p_irp in your list? You must remove an IRP from the Tail.Overlay
>> list before passing it to IoCallDriver. You should maintain the list by
>
> Could you so kindly to show me some code about how to do it?
>
>>
>> other means.
>> --
>> http://www.cristalink.com
>>
>>
>> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
>> news:uiryhqgn0.fsf@hotmail.com.discuss...
>>>I made a bda driver for our usb box. It seems working well until I
>>> unplug the power wire when it running in winxp+sp2.(it saids that it
>>> did not crash in win2k or winxp+sp1, so strange.)
>>>
>>> In the read data routine, I insert the irp to a list and in the
>>> complete routine I remove it from the list. Like this:
>>> (I simply use the global variables.)
>>> Insert:
>>> --8<---------------cut here---------------start------------->8---
>>> KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
>>> InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
>>> KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);
>>>
>>> status = IoCallDriver(p_devobj, p_irp);
>>> --8<---------------cut here---------------end--------------->8---
>>> Removal:
>>> --8<---------------cut here---------------start------------->8---
>>> KeAcquireSpinLock(&g_ks_pl, &old_irql);
>>>
>>> if (IsListEmpty(&g_irp_list))
>>> {
>>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>>> return FALSE;
>>> }
>>>
>>> RemoveHeadList(&g_irp_list);
>>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> After I unplug the power of the usb, winxp+sp2 would crash in
>>> usbport.sys. I commented out these codes, then unplug the power, no
>>> crash.
>>>
>>> I did not test the status of the irp, because I thought it was
>>> useless. I simply insert the irp to the queue and remove it after it
>>> completed.
>>>
>>> Could some one tell me what's wrong with my code?
>>> Advance thanks!
>>>

Maxim
Mon Aug 08 01:09:01 CDT 2005

Why ever keep the IRPs being sent down in a list?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"cristalink" <cristalink@nospam.nospam> wrote in message
news:uSQcMj9mFHA.3448@TK2MSFTNGP12.phx.gbl...
> The problem is, the lower drivers overwrites p_irp->Tail.Overlay.ListEntry,
> thus screwing up your list. When you then remove p_irp from the list, you
> are screwing up someone else's list.
>
> The simplest alternative is to maintain a list of structures containing
> pointers to IRPs. You'd need to allocate a structure per IRP, of course.
> Another way could be using your IO_STACK_LOCATION as LIST_ENTRY. Sorry, I
> don't have sample code at hand.
>
> --
> http://www.cristalink.com
>
>
> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
> news:uek95qcv4.fsf@hotmail.com.discuss...
> > "cristalink" <cristalink@nospam.nospam> writes:
> >
> >> How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry while
> >
> > I think it is using it. It would cause something? I inserted the
> > Tail.Overlay.ListEntry to my list before call IoCallDriver, and
> > removed it from my list after it returned from lower. Mybe I don't
> > understand well how to use Tail.Overlay.ListEntry, please feel free to
> > point out my mistakes.
> >
> >> you hold p_irp in your list? You must remove an IRP from the Tail.Overlay
> >> list before passing it to IoCallDriver. You should maintain the list by
> >
> > Could you so kindly to show me some code about how to do it?
> >
> >>
> >> other means.
> >> --
> >> http://www.cristalink.com
> >>
> >>
> >> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
> >> news:uiryhqgn0.fsf@hotmail.com.discuss...
> >>>I made a bda driver for our usb box. It seems working well until I
> >>> unplug the power wire when it running in winxp+sp2.(it saids that it
> >>> did not crash in win2k or winxp+sp1, so strange.)
> >>>
> >>> In the read data routine, I insert the irp to a list and in the
> >>> complete routine I remove it from the list. Like this:
> >>> (I simply use the global variables.)
> >>> Insert:
> >>> --8<---------------cut here---------------start------------->8---
> >>> KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
> >>> InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
> >>> KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);
> >>>
> >>> status = IoCallDriver(p_devobj, p_irp);
> >>> --8<---------------cut here---------------end--------------->8---
> >>> Removal:
> >>> --8<---------------cut here---------------start------------->8---
> >>> KeAcquireSpinLock(&g_ks_pl, &old_irql);
> >>>
> >>> if (IsListEmpty(&g_irp_list))
> >>> {
> >>> KeReleaseSpinLock(&g_ks_pl, old_irql);
> >>> return FALSE;
> >>> }
> >>>
> >>> RemoveHeadList(&g_irp_list);
> >>> KeReleaseSpinLock(&g_ks_pl, old_irql);
> >>> --8<---------------cut here---------------end--------------->8---
> >>>
> >>> After I unplug the power of the usb, winxp+sp2 would crash in
> >>> usbport.sys. I commented out these codes, then unplug the power, no
> >>> crash.
> >>>
> >>> I did not test the status of the irp, because I thought it was
> >>> useless. I simply insert the irp to the queue and remove it after it
> >>> completed.
> >>>
> >>> Could some one tell me what's wrong with my code?
> >>> Advance thanks!
> >>>
>
>

cristalink
Mon Aug 08 01:28:14 CDT 2005

> Why ever keep the IRPs being sent down in a list?

To cancel?

--
http://www.cristalink.com


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eHXMf%239mFHA.2916@TK2MSFTNGP14.phx.gbl...
> Why ever keep the IRPs being sent down in a list?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "cristalink" <cristalink@nospam.nospam> wrote in message
> news:uSQcMj9mFHA.3448@TK2MSFTNGP12.phx.gbl...
>> The problem is, the lower drivers overwrites
>> p_irp->Tail.Overlay.ListEntry,
>> thus screwing up your list. When you then remove p_irp from the list, you
>> are screwing up someone else's list.
>>
>> The simplest alternative is to maintain a list of structures containing
>> pointers to IRPs. You'd need to allocate a structure per IRP, of course.
>> Another way could be using your IO_STACK_LOCATION as LIST_ENTRY. Sorry, I
>> don't have sample code at hand.
>>
>> --
>> http://www.cristalink.com
>>
>>
>> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
>> news:uek95qcv4.fsf@hotmail.com.discuss...
>> > "cristalink" <cristalink@nospam.nospam> writes:
>> >
>> >> How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry
>> >> while
>> >
>> > I think it is using it. It would cause something? I inserted the
>> > Tail.Overlay.ListEntry to my list before call IoCallDriver, and
>> > removed it from my list after it returned from lower. Mybe I don't
>> > understand well how to use Tail.Overlay.ListEntry, please feel free to
>> > point out my mistakes.
>> >
>> >> you hold p_irp in your list? You must remove an IRP from the
>> >> Tail.Overlay
>> >> list before passing it to IoCallDriver. You should maintain the list
>> >> by
>> >
>> > Could you so kindly to show me some code about how to do it?
>> >
>> >>
>> >> other means.
>> >> --
>> >> http://www.cristalink.com
>> >>
>> >>
>> >> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
>> >> news:uiryhqgn0.fsf@hotmail.com.discuss...
>> >>>I made a bda driver for our usb box. It seems working well until I
>> >>> unplug the power wire when it running in winxp+sp2.(it saids that it
>> >>> did not crash in win2k or winxp+sp1, so strange.)
>> >>>
>> >>> In the read data routine, I insert the irp to a list and in the
>> >>> complete routine I remove it from the list. Like this:
>> >>> (I simply use the global variables.)
>> >>> Insert:
>> >>> --8<---------------cut here---------------start------------->8---
>> >>> KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
>> >>> InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
>> >>> KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);
>> >>>
>> >>> status = IoCallDriver(p_devobj, p_irp);
>> >>> --8<---------------cut here---------------end--------------->8---
>> >>> Removal:
>> >>> --8<---------------cut here---------------start------------->8---
>> >>> KeAcquireSpinLock(&g_ks_pl, &old_irql);
>> >>>
>> >>> if (IsListEmpty(&g_irp_list))
>> >>> {
>> >>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>> >>> return FALSE;
>> >>> }
>> >>>
>> >>> RemoveHeadList(&g_irp_list);
>> >>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>> >>> --8<---------------cut here---------------end--------------->8---
>> >>>
>> >>> After I unplug the power of the usb, winxp+sp2 would crash in
>> >>> usbport.sys. I commented out these codes, then unplug the power, no
>> >>> crash.
>> >>>
>> >>> I did not test the status of the irp, because I thought it was
>> >>> useless. I simply insert the irp to the queue and remove it after it
>> >>> completed.
>> >>>
>> >>> Could some one tell me what's wrong with my code?
>> >>> Advance thanks!
>> >>>
>>
>>
>
>

WilliamX
Mon Aug 08 01:40:33 CDT 2005

"cristalink" <cristalink@nospam.nospam> writes:

>> Why ever keep the IRPs being sent down in a list?
>
> To cancel?

Yes!

>
> --
> http://www.cristalink.com
>
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:eHXMf%239mFHA.2916@TK2MSFTNGP14.phx.gbl...
>> Why ever keep the IRPs being sent down in a list?
>>
>> --
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> maxim@storagecraft.com
>> http://www.storagecraft.com

WilliamX
Mon Aug 08 02:04:54 CDT 2005

"cristalink" <cristalink@nospam.nospam> writes:

> The problem is, the lower drivers overwrites p_irp->Tail.Overlay.ListEntry,
> thus screwing up your list. When you then remove p_irp from the list, you
> are screwing up someone else's list.

But the strange thing is that the crash only occured after unplug the
power (when it is running). It runs O.K. and it is O.K. even when
stopped regularly.

And, though I have not checked, as reported back, it would not cause a
crash in win2k and winxp+sp1.

Maybe the situation which you refered to is a mine?

>
> The simplest alternative is to maintain a list of structures containing
> pointers to IRPs. You'd need to allocate a structure per IRP, of course.
> Another way could be using your IO_STACK_LOCATION as LIST_ENTRY. Sorry, I
> don't have sample code at hand.
>

Yes, I have rounded this issue.

>
> --
> http://www.cristalink.com
>
>
> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
> news:uek95qcv4.fsf@hotmail.com.discuss...
>> "cristalink" <cristalink@nospam.nospam> writes:
>>
>>> How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry while
>>
>> I think it is using it. It would cause something? I inserted the
>> Tail.Overlay.ListEntry to my list before call IoCallDriver, and
>> removed it from my list after it returned from lower. Mybe I don't
>> understand well how to use Tail.Overlay.ListEntry, please feel free to
>> point out my mistakes.
>>
>>> you hold p_irp in your list? You must remove an IRP from the Tail.Overlay
>>> list before passing it to IoCallDriver. You should maintain the list by
>>
>> Could you so kindly to show me some code about how to do it?
>>
>>>
>>> other means.
>>> --
>>> http://www.cristalink.com
>>>
>>>
>>> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
>>> news:uiryhqgn0.fsf@hotmail.com.discuss...
>>>>I made a bda driver for our usb box. It seems working well until I
>>>> unplug the power wire when it running in winxp+sp2.(it saids that it
>>>> did not crash in win2k or winxp+sp1, so strange.)
>>>>
>>>> In the read data routine, I insert the irp to a list and in the
>>>> complete routine I remove it from the list. Like this:
>>>> (I simply use the global variables.)
>>>> Insert:
>>>> --8<---------------cut here---------------start------------->8---
>>>> KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
>>>> InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
>>>> KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);
>>>>
>>>> status = IoCallDriver(p_devobj, p_irp);
>>>> --8<---------------cut here---------------end--------------->8---
>>>> Removal:
>>>> --8<---------------cut here---------------start------------->8---
>>>> KeAcquireSpinLock(&g_ks_pl, &old_irql);
>>>>
>>>> if (IsListEmpty(&g_irp_list))
>>>> {
>>>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>>>> return FALSE;
>>>> }
>>>>
>>>> RemoveHeadList(&g_irp_list);
>>>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>>> After I unplug the power of the usb, winxp+sp2 would crash in
>>>> usbport.sys. I commented out these codes, then unplug the power, no
>>>> crash.
>>>>
>>>> I did not test the status of the irp, because I thought it was
>>>> useless. I simply insert the irp to the queue and remove it after it
>>>> completed.
>>>>
>>>> Could some one tell me what's wrong with my code?
>>>> Advance thanks!
>>>>

cristalink
Mon Aug 08 04:15:43 CDT 2005

> But the strange thing

There's nothing strange here. Your original approach is simply wrong. It
might work is some circumstances, but will crash the system in most other
cases.
--
http://www.cristalink.com


"WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
news:u64ugrjs9.fsf@hotmail.com.discuss...
> "cristalink" <cristalink@nospam.nospam> writes:
>
>> The problem is, the lower drivers overwrites
>> p_irp->Tail.Overlay.ListEntry,
>> thus screwing up your list. When you then remove p_irp from the list, you
>> are screwing up someone else's list.
>
> But the strange thing is that the crash only occured after unplug the
> power (when it is running). It runs O.K. and it is O.K. even when
> stopped regularly.
>
> And, though I have not checked, as reported back, it would not cause a
> crash in win2k and winxp+sp1.
>
> Maybe the situation which you refered to is a mine?
>
>>
>> The simplest alternative is to maintain a list of structures containing
>> pointers to IRPs. You'd need to allocate a structure per IRP, of course.
>> Another way could be using your IO_STACK_LOCATION as LIST_ENTRY. Sorry, I
>> don't have sample code at hand.
>>
>
> Yes, I have rounded this issue.
>
>>
>> --
>> http://www.cristalink.com
>>
>>
>> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
>> news:uek95qcv4.fsf@hotmail.com.discuss...
>>> "cristalink" <cristalink@nospam.nospam> writes:
>>>
>>>> How do you know p_devobj is not using p_irp->Tail.Overlay.ListEntry
>>>> while
>>>
>>> I think it is using it. It would cause something? I inserted the
>>> Tail.Overlay.ListEntry to my list before call IoCallDriver, and
>>> removed it from my list after it returned from lower. Mybe I don't
>>> understand well how to use Tail.Overlay.ListEntry, please feel free to
>>> point out my mistakes.
>>>
>>>> you hold p_irp in your list? You must remove an IRP from the
>>>> Tail.Overlay
>>>> list before passing it to IoCallDriver. You should maintain the list by
>>>
>>> Could you so kindly to show me some code about how to do it?
>>>
>>>>
>>>> other means.
>>>> --
>>>> http://www.cristalink.com
>>>>
>>>>
>>>> "WilliamX" <fantast_xue@hotmail.com.discuss> wrote in message
>>>> news:uiryhqgn0.fsf@hotmail.com.discuss...
>>>>>I made a bda driver for our usb box. It seems working well until I
>>>>> unplug the power wire when it running in winxp+sp2.(it saids that it
>>>>> did not crash in win2k or winxp+sp1, so strange.)
>>>>>
>>>>> In the read data routine, I insert the irp to a list and in the
>>>>> complete routine I remove it from the list. Like this:
>>>>> (I simply use the global variables.)
>>>>> Insert:
>>>>> --8<---------------cut here---------------start------------->8---
>>>>> KeAcquireSpinLock(&g_ks_pl, &g_old_pk_irql);
>>>>> InsertTailList(&g_irp_list, &p_irp->Tail.Overlay.ListEntry);
>>>>> KeReleaseSpinLock(&g_ks_pl, g_old_pk_irql);
>>>>>
>>>>> status = IoCallDriver(p_devobj, p_irp);
>>>>> --8<---------------cut here---------------end--------------->8---
>>>>> Removal:
>>>>> --8<---------------cut here---------------start------------->8---
>>>>> KeAcquireSpinLock(&g_ks_pl, &old_irql);
>>>>>
>>>>> if (IsListEmpty(&g_irp_list))
>>>>> {
>>>>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>>>>> return FALSE;
>>>>> }
>>>>>
>>>>> RemoveHeadList(&g_irp_list);
>>>>> KeReleaseSpinLock(&g_ks_pl, old_irql);
>>>>> --8<---------------cut here---------------end--------------->8---
>>>>>
>>>>> After I unplug the power of the usb, winxp+sp2 would crash in
>>>>> usbport.sys. I commented out these codes, then unplug the power, no
>>>>> crash.
>>>>>
>>>>> I did not test the status of the irp, because I thought it was
>>>>> useless. I simply insert the irp to the queue and remove it after it
>>>>> completed.
>>>>>
>>>>> Could some one tell me what's wrong with my code?
>>>>> Advance thanks!
>>>>>

Mark
Mon Aug 08 06:14:16 CDT 2005

WilliamX wrote:
> "cristalink" <cristalink@nospam.nospam> writes:
>
>
>>> Why ever keep the IRPs being sent down in a list?
>>
>>To cancel?
>
>
> Yes!
>

No. If you need to keep track of an IRP you are sending down the stack
you need to allocate a separate context structure that points to the IRP
and queue that rather than the IRP itself.

You do not handle cancellation of IRPs that you have sent to a lower
driver, they are not your responsiblity to cancel - the 'current IRP
owner' handles cancellation, once you have passed the IRP down you are
not the current IRP owner. If you intend to initiate cancellation of
IRPs, rather than handle cancellation initiated by the OS or the IO
initiator, then first that can be tricky to do correctly, and second
that would be a case where using a context structure to hold a pointer
to an IRP would be the right approach.

>
>>--
>>http://www.cristalink.com
>>
>>
>>"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>>news:eHXMf%239mFHA.2916@TK2MSFTNGP14.phx.gbl...
>>
>>> Why ever keep the IRPs being sent down in a list?
>>>
>>>--
>>>Maxim Shatskih, Windows DDK MVP
>>>StorageCraft Corporation
>>>maxim@storagecraft.com
>>>http://www.storagecraft.com


--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

WilliamX
Mon Aug 08 06:46:00 CDT 2005

"cristalink" <cristalink@nospam.nospam> writes:

> The problem is, the lower drivers overwrites p_irp->Tail.Overlay.ListEntry,
> thus screwing up your list. When you then remove p_irp from the list, you
> are screwing up someone else's list.

Thanks.

>
> The simplest alternative is to maintain a list of structures containing
> pointers to IRPs. You'd need to allocate a structure per IRP, of course.
> Another way could be using your IO_STACK_LOCATION as LIST_ENTRY. Sorry, I

Use IO_STACK_LOCATION as LIST_ENTRY ? Could you so kindly to explain it
in detail?

> don't have sample code at hand.
>
> --
> http://www.cristalink.com
>

cristalink
Mon Aug 08 06:57:00 CDT 2005

You seem to confuse "handling" with "initiating". If you send down IRPs and
you want to cancel them, you maintain the list to call IoCancelIrp for every
IRP in the list. Then the "current owner", ie the lower driver, will handle
cancellation.

--
http://www.cristalink.com



"Mark Roddy" <markr@hollistech.com> wrote in message
news:OC4ORpAnFHA.2156@TK2MSFTNGP14.phx.gbl...
> WilliamX wrote:
>> "cristalink" <cristalink@nospam.nospam> writes:
>>
>>
>>>> Why ever keep the IRPs being sent down in a list?
>>>
>>>To cancel?
>>
>>
>> Yes!
>>
>
> No. If you need to keep track of an IRP you are sending down the stack you
> need to allocate a separate context structure that points to the IRP and
> queue that rather than the IRP itself.
>
> You do not handle cancellation of IRPs that you have sent to a lower
> driver, they are not your responsiblity to cancel - the 'current IRP
> owner' handles cancellation, once you have passed the IRP down you are not
> the current IRP owner. If you intend to initiate cancellation of IRPs,
> rather than handle cancellation initiated by the OS or the IO initiator,
> then first that can be tricky to do correctly, and second that would be a
> case where using a context structure to hold a pointer to an IRP would be
> the right approach.
>
>>
>>>--
>>>http://www.cristalink.com
>>>
>>>
>>>"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>>>news:eHXMf%239mFHA.2916@TK2MSFTNGP14.phx.gbl...
>>>
>>>> Why ever keep the IRPs being sent down in a list?
>>>>
>>>>--
>>>>Maxim Shatskih, Windows DDK MVP
>>>>StorageCraft Corporation
>>>>maxim@storagecraft.com
>>>>http://www.storagecraft.com
>
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com

Mark
Mon Aug 08 19:08:36 CDT 2005

cristalink wrote:
> You seem to confuse "handling" with "initiating". If you send down IRPs and
> you want to cancel them, you maintain the list to call IoCancelIrp for every
> IRP in the list. Then the "current owner", ie the lower driver, will handle
> cancellation.
>

I'm confused?

I said:
"You do not handle cancellation of IRPs that you have sent to a lower
driver, they are not your responsiblity to cancel - the 'current IRP
owner' handles cancellation, once you have passed the IRP down you are
not the current IRP owner. If you intend to initiate cancellation of
IRPs, rather than handle cancellation initiated by the OS or the IO
initiator, then first that can be tricky to do correctly, and second
that would be a case where using a context structure to hold a pointer
to an IRP would be the right approach."

I'm missing the part where I am confused.


> --
> http://www.cristalink.com
>
>
>
> "Mark Roddy" <markr@hollistech.com> wrote in message
> news:OC4ORpAnFHA.2156@TK2MSFTNGP14.phx.gbl...
>
>>WilliamX wrote:
>>
>>>"cristalink" <cristalink@nospam.nospam> writes:
>>>
>>>
>>>
>>>>> Why ever keep the IRPs being sent down in a list?
>>>>
>>>>To cancel?
>>>
>>>
>>>Yes!
>>>
>>
>>No. If you need to keep track of an IRP you are sending down the stack you
>>need to allocate a separate context structure that points to the IRP and
>>queue that rather than the IRP itself.
>>
>>You do not handle cancellation of IRPs that you have sent to a lower
>>driver, they are not your responsiblity to cancel - the 'current IRP
>>owner' handles cancellation, once you have passed the IRP down you are not
>>the current IRP owner. If you intend to initiate cancellation of IRPs,
>>rather than handle cancellation initiated by the OS or the IO initiator,
>>then first that can be tricky to do correctly, and second that would be a
>>case where using a context structure to hold a pointer to an IRP would be
>>the right approach.
>>
>>
>>>>--
>>>>http://www.cristalink.com
>>>>
>>>>
>>>>"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>>>>news:eHXMf%239mFHA.2916@TK2MSFTNGP14.phx.gbl...
>>>>
>>>>
>>>>> Why ever keep the IRPs being sent down in a list?
>>>>>
>>>>>--
>>>>>Maxim Shatskih, Windows DDK MVP
>>>>>StorageCraft Corporation
>>>>>maxim@storagecraft.com
>>>>>http://www.storagecraft.com
>>
>>
>>--
>>
>>=====================
>>Mark Roddy DDK MVP
>>Windows 2003/XP/2000 Consulting
>>Hollis Technology Solutions 603-321-1032
>>www.hollistech.com
>
>
>


--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

cristalink
Mon Aug 08 20:16:02 CDT 2005

Mark,

"Mark Roddy" <markr@hollistech.com> wrote in message
news:OC4ORpAnFHA.2156@TK2MSFTNGP14.phx.gbl...
> WilliamX wrote:
>> "cristalink" <cristalink@nospam.nospam> writes:
>>
>>
>>>> Why ever keep the IRPs being sent down in a list?
>>>
>>>To cancel?
>>
>>
>> Yes!
>>
>
> No.

Could you clarify what exactly you disagree with? You said: "You do not
handle cancellation of IRPs that you have sent to a lower driver, they are
not your responsibility to cancel". Who are you arguing with? I'm sorry, may
be I missed some post.

Cheers



"Mark Roddy" <markr@hollistech.com> wrote in message
news:%23tC%239ZHnFHA.3828@TK2MSFTNGP12.phx.gbl...
> cristalink wrote:
>> You seem to confuse "handling" with "initiating". If you send down IRPs
>> and you want to cancel them, you maintain the list to call IoCancelIrp
>> for every IRP in the list. Then the "current owner", ie the lower driver,
>> will handle cancellation.
>>
>
> I'm confused?
>
> I said:
> "You do not handle cancellation of IRPs that you have sent to a lower
> driver, they are not your responsiblity to cancel - the 'current IRP
> owner' handles cancellation, once you have passed the IRP down you are not
> the current IRP owner. If you intend to initiate cancellation of IRPs,
> rather than handle cancellation initiated by the OS or the IO initiator,
> then first that can be tricky to do correctly, and second that would be a
> case where using a context structure to hold a pointer to an IRP would be
> the right approach."
>
> I'm missing the part where I am confused.
>
>
>> --
>> http://www.cristalink.com
>>
>>
>>
>> "Mark Roddy" <markr@hollistech.com> wrote in message
>> news:OC4ORpAnFHA.2156@TK2MSFTNGP14.phx.gbl...
>>
>>>WilliamX wrote:
>>>
>>>>"cristalink" <cristalink@nospam.nospam> writes:
>>>>
>>>>
>>>>
>>>>>> Why ever keep the IRPs being sent down in a list?
>>>>>
>>>>>To cancel?
>>>>
>>>>
>>>>Yes!
>>>>
>>>
>>>No. If you need to keep track of an IRP you are sending down the stack
>>>you need to allocate a separate context structure that points to the IRP
>>>and queue that rather than the IRP itself.
>>>
>>>You do not handle cancellation of IRPs that you have sent to a lower
>>>driver, they are not your responsiblity to cancel - the 'current IRP
>>>owner' handles cancellation, once you have passed the IRP down you are
>>>not the current IRP owner. If you intend to initiate cancellation of
>>>IRPs, rather than handle cancellation initiated by the OS or the IO
>>>initiator, then first that can be tricky to do correctly, and second that
>>>would be a case where using a context structure to hold a pointer to an
>>>IRP would be the right approach.
>>>
>>>
>>>>>--
>>>>>http://www.cristalink.com
>>>>>
>>>>>
>>>>>"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>>>>>news:eHXMf%239mFHA.2916@TK2MSFTNGP14.phx.gbl...
>>>>>
>>>>>
>>>>>> Why ever keep the IRPs being sent down in a list?
>>>>>>
>>>>>>--
>>>>>>Maxim Shatskih, Windows DDK MVP
>>>>>>StorageCraft Corporation
>>>>>>maxim@storagecraft.com
>>>>>>http://www.storagecraft.com
>>>
>>>
>>>--
>>>
>>>=====================
>>>Mark Roddy DDK MVP
>>>Windows 2003/XP/2000 Consulting
>>>Hollis Technology Solutions 603-321-1032
>>>www.hollistech.com
>>
>>
>>
>
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com

WilliamX
Tue Aug 09 01:35:59 CDT 2005

Mark Roddy <markr@hollistech.com> writes:

> WilliamX wrote:
>> "cristalink" <cristalink@nospam.nospam> writes:
>>
>>>> Why ever keep the IRPs being sent down in a list?
>>>
>>>To cancel?
>> Yes!
>>
>
> No. If you need to keep track of an IRP you are sending down the stack
> you need to allocate a separate context structure that points to the IRP
> and queue that rather than the IRP itself.

Yes! It's ok now. Thank you very much!

>
> You do not handle cancellation of IRPs that you have sent to a lower
> driver, they are not your responsiblity to cancel - the 'current IRP
> owner' handles cancellation, once you have passed the IRP down you are
> not the current IRP owner. If you intend to initiate cancellation of
> IRPs, rather than handle cancellation initiated by the OS or the IO
> initiator, then first that can be tricky to do correctly, and second
> that would be a case where using a context structure to hold a pointer
> to an IRP would be the right approach.

I just want to call IoCancelIrp to cancel the irps(set the cancel flag,
let the irp return immediately?) which created by IoAllocateIrp in my
routine.

>
>
>>
>>> --
>>>http://www.cristalink.com
>>>
>>>
>>> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>>> news:eHXMf%239mFHA.2916@TK2MSFTNGP14.phx.gbl...
>>>
>>>> Why ever keep the IRPs being sent down in a list?
>>>>
>>>> --
>>>>Maxim Shatskih, Windows DDK MVP
>>>>StorageCraft Corporation
>>>>maxim@storagecraft.com
>>>>http://www.storagecraft.com
>
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com