A couple of “is it plugged in?” type questions:
- I assume that you are calling the function at DIRQL that fails on the next interrupt from the device.
- Does “sending it to the hardware” mean that you give the pointer to the IRP to the “hardware”?
- Does “the hardware” “understand” the IRP contents? Does it read & write it?
- Are you sure that the IRP address is the same in both cases?
- The IRP is marked pending and you’ve returned STATUS_PENDING?
-DH
PS. I always considered it bad form to pass a memory address to external hardware, and then accept that back on an interrupt
without validating it.
----- Original Message -----
From: “Gary Little”
To: “NT Developers Interest List”
Sent: Thursday, March 08, 2001 12:05 PM
Subject: [ntdev] Re: [NTDEV] Rules for the use of IoGetCurrentIrpStack Location in Windows 2000
> Peter,
>
> Yeah, race conditions are always a possibility, but in this instance I can’t
> see where that would apply. The IRP is sent to the hardware, not hung on any
> queues, and not seen again until the hardware interrupts. Since this is a
> special request type operation, access to the IRP is very restricted with
> only the dispatch routine that sends it to the hardware, the ISR, and the
> DPC that completes it ever seeing it.
>
> I just noticed that after sending it to the hardware and the waiting on the
> hardware interrupt to complete the IRP, that is waiting without a cancel
> routine. Oops, that’s a bug, but that should not affect whether or not
> I can acquire a pointer to the current stack location at DIRQL.
>
> Gary G. Little
> Sr. Staff Engineer
> Broadband Storage, LLC
> xxxxx@broadstor.com
> xxxxx@delphieng.com
>
>
> -----Original Message-----
> From: Peter Viscarola [mailto:xxxxx@osr.com]
> Sent: Wednesday, March 07, 2001 2:46 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: [NTDEV] Rules for the use of
> IoGetCurrentIrpStackLocation in Windows 2000
>
>
> “Gary G. Little” wrote in message news:xxxxx@ntdev…
> > DISPATCH_LEVEL… I see no reason why IRQL should be a restriction since
> all
> > IGCISL does is fetch the CurrentStackLocation field in the Tail.Overlay
> > structure of the IRP.
> >
>
> Me either. This is entirely safe.
>
> >
> > However, why are CurrentStackLocation NULL and
> > CurrentLocation 4?
> >
>
> Ugh. Well, THAT’s a harder question, isn’t it. The ONLY thing I can guess
> is an ordinary, garden-variety type bug in your driver. Perhaps you’ve got
> a race condition involving this IRP somewhere/somehow? Sorry, Gary, I know
> that’s not a very satisfying answer, but that’s all I can think of to
> suggest.
>
> There certainly is no problem calling IoGetCurrentIrpStackLocation() from
> your ISR.
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@delphieng.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com