Hi Pete
Thanks for the reply . I observed that there is no stack location allocated
for the current stack location . The pointer it shows is 4 bytes below the
total allocation and it is supposed to have another 32 bytes after that and
I don’t see any allocation of memory for the current stack location. I think
this is the reason why it is causing BSOD . It looks like we cannot touch
current stack location after creating IRP . The current stack location is
showing correctly in case of failure mode . Back to my original question, if
there is no current stack location after creating IRP , how come it behaves
differently in other OS’s ?
Can we generalize it that there won’t be any current stack location with
IoAllocateIrp ?
If so IoAllocateIrp is behaving differently on different machines ?
This is the data I captured in Windbg :
FILTER: FltrCreateIrp, irpsp =0xaf803fd8
START IRP PRINTING>>>>>>>>>
PIRP
Type = 0x6
Size = 0x124
MdlAddress = 0x0
Flags = 0x0
AssociatedIrp.MasterIrp = 0x0
AssociatedIrp.IrpCount = 0x0
AssociatedIrp.SystemBuffer = 0x0
ThreadListEntry.Flink = 0xaf803ee8
ThreadListEntry.Blink = 0xaf803ee8
IoStatus.Status = 0x0
IoStatus.Pointer = 0x0
IoStatus.Information = 0x0
RequestorMode = 0x0
PendingReturned = 0x0
StackCount = 0x5
CurrentLocation = 0x6
Cancel = 0x0
CancelIrql = 0x0
ApcEnvironment = 0x0
AllocationFlags = 0x0
UserIosb = 0x0
UserEvent = 0x0
Overlay.AsynchronousParameters.UserApcRoutine = 0x0
Overlay.AsynchronousParameters.UserApcContext = 0x0
CancelRoutine = 0x0
UserBuffer = 0x0
Tail.Overlay.DeviceQueueEntry.DeviceListEntry.Flink = 0x0
Tail.Overlay.DeviceQueueEntry.DeviceListEntry.Blink = 0x0
Tail.Overlay.DeviceQueueEntry.SortKey = 0x0
Tail.Overlay.DeviceQueueEntry.Inserted = 0x0
Tail.Overlay.DriverContext[0] = 0x0
Tail.Overlay.DriverContext[1] = 0x0
Tail.Overlay.DriverContext[2] = 0x0
Tail.Overlay.DriverContext[3] = 0x0
Tail.Overlay.Thread = 0x0
Tail.Overlay.AuxiliaryBuffer = 0x0
Tail.Overlay.ListEntry.Flink = 0x0
Tail.Overlay.ListEntry.Blink = 0x0
Tail.Overlay.CurrentStackLocation = 0xaf803ffc
Tail.Overlay.PacketType = 0xaf803ffc
Tail.Overlay.OriginalFileObject = 0x0
Tail.Apc.Type = 0x0
Tail.Apc.Size = 0x0
Tail.Apc.Spare0 = 0x0
Tail.Apc.Thread = 0x0
Tail.Apc.ApcListEntry.Flink = 0x0
Tail.Apc.ApcListEntry.Blink = 0x0
Tail.Apc.KernelRoutine = 0x0
Tail.Apc.RundownRoutine = 0x0
Tail.Apc.NormalRoutine = 0x0
Tail.Apc.NormalContext = 0xaf803ffc
Tail.Apc.SystemArgument1 = 0x0
Tail.Apc.SystemArgument2 = 0x0
Tail.Apc.ApcStateIndex = 0x0
Tail.Apc.Inserted = 0x0
Tail.CompletionKey = 0x0
IRP SP ///// These are next IRP stack location parameters **********
MajorFunction = 0x4
MinorFunction = 0x0
Flags = 0x0
Control = 0x0
Parameters.Read.Length = 0x0
Parameters.Read.Key = 0x0
Parameters.Read.ByteOffset.LowPart = 0x0
Parameters.Read.ByteOffset.HighPart = 0x0
Parameters.Write.Length = 0x0
Parameters.Write.Key = 0x0
Parameters.Write.ByteOffset.LowPart = 0x0
Parameters.Write.ByteOffset.HighPart = 0x0
Parameters.DeviceIoControl.OutputBufferLength = 0x0
Parameters.DeviceIoControl.InputBufferLength = 0x0
Parameters.DeviceIoControl.IoControlCode = 0x0
Parameters.DeviceIoControl.Type3InputBuffer = 0x0
CompletionRoutine = 0x0
Context = 0x0
>>>>>>>>END IRP PRINTING
FILTER: FltrCreateIrp, buff=0x0
FILTER: Leaving FltrCreateIrp, irp=0xaf803ed8
Fltr_Dispatch: IRP_MJ_CREATE : Create Read Irp
FILTER: FltrCreateIrp, MajorFunc=0x3, ss=4
FILTER: FltrCreateIrp, irpsp =0xafb91fd8
START IRP PRINTING>>>>>>>>>
The memory dump looks like :
af803ecc 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 06 00 24 01 …$.
af803edc 00 00 00 00 00 00 00 00 00 00 00 00 e8 3e 80 af …>…
af803eec e8 3e 80 af 00 00 00 00 00 00 00 00 00 00 05 06 .>…
af803efc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f1c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f2c 00 00 00 00 00 00 00 00 00 00 00 00 fc 3f 80 af …?..
af803f3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f5c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f6c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f7c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f8c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803f9c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803fac 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803fbc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803fcc 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 …
af803fdc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803fec 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
af803ffc 9c 9c 9c 9c ??? ??? ??? ??? ??? ???
??? ??? ??? ??? ??? ???
…???
af80400c ??? ??? ??? ??? ??? ??? ???
??? ??? ??? ??? ??? ??? ???
??? ??? ???
af80401c ??? ??? ??? ??? ??? ??? ???
??? ??? ??? ??? ??? ??? ???
??? ??? ???
af80402c ??? ??? ??? ??? ??? ??? ???
Thanks in advance
srinivas
-----Original Message-----
From: Pete Scott [mailto:xxxxx@KernelDrivers.com]
Sent: Friday, January 04, 2002 5:39 PM
To: NT Developers Interest List
Subject: [ntdev] Re: IoGetCurrentIrpStackLocation call causes BSOD
See below …
Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Srinivasa Rao Deevi
Sent: Friday, January 04, 2002 5:45 PM
To: NT Developers Interest List
Subject: [ntdev] Re: IoGetCurrentIrpStackLocation call causes BSOD
Hi Peter
You are right . It is not IoGetCurrentIrpStackLocation causing the BSOD .
But using the stack location when I was trying to store some parameters is
causing the BSOD.Even though it allocates a current location , can we not
store any parameters in to that ?
> Well, you may be able to but you could very well be corrupting some part
of the Irp that you shouldn’t be, which isn’t good .
In a OSR article : //www.osr.com/ntinsider/1997/iocomp/iocomp.htm
" When the IRP is first created, the current IRP stack location is not valid
and calling IoGetCurrentIrpStackLocation() will return a pointer to a
location inside of the IRP structure itself. However, the next IRP stack
location, retrieved by using IoGetNextIrpStackLocation() is valid and in
fact is used when setting up the parameters for the first driver to be
called (the mechanics of setting up the first I/O stack location were
described in the article “Rolling Your Own” , The NT Insider V4N1)."
- Does that mean we should not use to store any parameters even though it
allocates the current stack location ?
> When the Irp is allocated the Stack is allocated off the end of the Irp,
not a seperate allocation, and the Stack locations reference an offset to
this location within the allocated block. This is why you pass the stack
count when allocating an Irp. So, since the current location has a valid
offset into somewhere within the allocated block, it is only set so that
when the Irp is passed to the next driver, the stack location parameters are
appropriately updated. You will get back a location that will overwrite some
portion of the Irp not setup for the stack. In other words … don’t store
parameters within the current stack location.
How come it works on one machine and does not on antoher OS ( both are
windows 2000 only) ?
> Check the Currentstacklocation parameters in the cases that fail and see
where it points to …
Thanks in advance
srinivas
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Friday, January 04, 2002 3:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: IoGetCurrentIrpStackLocation call causes BSOD
“Srinivasa Rao Deevi” wrote in message
news:xxxxx@ntdev…
>
> Thanks for the reply. I understand your point . I have a question here .
> what kind of explanaiton we can give on one OS it works and does n’t on
> another OS when we call IoGetCurrentIrpStackLocation ? I agree with you
that
> we don’t need current stack location .
>
It NEVER works. As Pete said, the allocator does HAVE an I/O Stack
Location.
Having said that, it might not crash the system.
IoGetCurrentIrpStackLocation is a macro in wdm.h or ntddk.h – Have a look,
and you’ll see what it does.
Peter
OSR
—
You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microtune.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