Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
text>
RE: NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP is passed down - simple passthru fi
I thought that produce the ‘no more irp stack locations’ bugcheck, but it
does seem to be the obvious cause of the problem.
=====================
Mark Roddy
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, May 13, 2004 3:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP is passed down - simple passthru filter driver included
Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
text>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
It would, but he is hand incrementing the stack location… so I think that
might bypass the check.
-Jeff
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 13, 2004 3:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP is passed down - simple passthru filter driver included
I thought that produce the ‘no more irp stack locations’ bugcheck, but it
does seem to be the obvious cause of the problem.
=====================
Mark Roddy
_____
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, May 13, 2004 3:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP is passed down - simple passthru filter driver included
Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
text>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks for the feedback.
When ASPI32.SYS is manually creating the IRP using a call to
IoBuildDeviceIoControlRequest
how does the I/O Manager know how big of I/O stack to create for
this IRP? Does the I/O Manager look at the target DeviceObject
parameter in this call for the StackSize?
This filter driver is attached to \Device\ScsiPort2 which
is SCSIPORT device object, and ASPI32.SYS which sits on top of this
filter driver is not aware of the filter driver underneath. When
ASPI32.SYS manually creates this internal device control IRP
for SCSIPORT, it gets to my filter driver, i don’t process it but
skip the stack and pass it on to SCSIPORT, so there shouldn’t be
a problem of I/O stack space over running or running out.
That is, the original I/O stack size for the ASPI32 IRP should work
just fine through my filter driver and to SCSIPORT.
Without this filter driver present however, there’s no problem.
So there’s something i’m doing wrong in my filter driver.
FYI, dumping the ASPI IRP i receive in my dispatch routine shows
following information,
kd> !irp 808754c8
Irp is active with 2 stacks 3 is current
No Mdl Thread 807a88c0: Irp is completed.
cmd flg cl Device File Completion-Context
0 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000
00000000 00000000
f 0 e0 8090c020 00000000 f73a225e-80810758 Success Error Cancel
\Driver\sipeswn4 Aspi32
Args: 80810785 00000000
808a7920 80188760
The fact the “Irp is active with 2 stacks 3 is current”, is
that an obvious problem?
Regards,
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Roddy, Mark”
Sent by: xxxxx@lists.osr.com
05/13/2004 01:27 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
I thought that produce the ‘no more irp stack locations’ bugcheck, but it
does seem to be the obvious cause of the problem.
=====================
Mark Roddy
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, May 13, 2004 3:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
64k text>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
So my understanding is that a filter driver that doesn’t add any
completion routine and all that does is passing on the IRP to next
guy down, should do this incrementing of stack location so that
the next lower driver sees the correct I/O stack intended for it
by upper-level driver, eg. ASPI32.SYS which sits on top of my
filter driver.
So i believe i’m doing everything that should be done to not mess
up the I/O stack.
However the problem is, if IRP has data transfer request (eg.
SCSI READ, WRITE, INQUIRY) then that leads to crash. But if IRP does
not data transfer, eg. SCSI TEST UNIT READY, START STOP UNIT, then
the command is processed just fine and no crash.
Just bizzare… I’m just almost point of having no hair…
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Curless, Jeffrey”
Sent by: xxxxx@lists.osr.com
05/13/2004 02:34 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
It would, but he is hand incrementing the stack location… so I think
that might bypass the check.
-Jeff
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 13, 2004 3:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
I thought that produce the ‘no more irp stack locations’ bugcheck, but it
does seem to be the obvious cause of the problem.
=====================
Mark Roddy
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, May 13, 2004 3:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
64k text>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Yes that looks like a problem to me. Are you using the
IoSkipCurrentIrpStackLocation
macro to skip the stack location? Or are you doing it manually. You should
always use the macros when fiddling with IRP stack locations.
-Jeff
-----Original Message-----
From: xxxxx@deadlinemavens.dtdns.net
[mailto:xxxxx@deadlinemavens.dtdns.net]
Sent: Thursday, May 13, 2004 5:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP is passed down - simple passthru filter driver included
So my understanding is that a filter driver that doesn’t add any completion
routine and all that does is passing on the IRP to next guy down, should do
this incrementing of stack location so that the next lower driver sees the
correct I/O stack intended for it by upper-level driver, eg. ASPI32.SYS
which sits on top of my filter driver.
So i believe i’m doing everything that should be done to not mess up the I/O
stack.
However the problem is, if IRP has data transfer request (eg. SCSI READ,
WRITE, INQUIRY) then that leads to crash. But if IRP does not data transfer,
eg. SCSI TEST UNIT READY, START STOP UNIT, then the command is processed
just fine and no crash.
Just bizzare… I’m just almost point of having no hair…
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Curless, Jeffrey”
Sent by: xxxxx@lists.osr.com
05/13/2004 02:34 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only
when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
It would, but he is hand incrementing the stack location… so I think
that might bypass the check.
-Jeff
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 13, 2004 3:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP
is passed down - simple passthru filter driver included
I thought that produce the ‘no more irp stack locations’ bugcheck, but it
does seem to be the obvious cause of the problem.
=====================
Mark Roddy
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, May 13, 2004 3:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP
is passed down - simple passthru filter driver included
Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
64k text>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
> You should
always use the macros when fiddling with IRP stack locations.
Yes, agreed but that macro isn’t available on NT4 DDK, so i’m doing
it manually however the net effect is the same.
This is what the IoSkipCurrentIrpStackLocation macro is in Windows
2000/XP DDK (ntddk.h for both w2k and wxp),
15732 //++
15733 //
15734 // VOID
15735 // IoSkipCurrentIrpStackLocation (
15736 // IN PIRP Irp
15737 // )
15738 //
15739 // Routine Description:
15740 //
15741 // This routine is invoked to increment the current stack
location of
15742 // a given IRP.
15743 //
15744 // If the caller wishes to call the next driver in a stack,
and does not
15745 // wish to change the arguments, nor does he wish to set a
completion
15746 // routine, then the caller first calls
IoSkipCurrentIrpStackLocation
15747 // and the calls IoCallDriver.
15748 //
15749 // Arguments:
15750 //
15751 // Irp - Pointer to the I/O Request Packet.
15752 //
15753 // Return Value:
15754 //
15755 // None
15756 //
15757 //–
15758
15759 #define IoSkipCurrentIrpStackLocation( Irp ) \
15760 (Irp)->CurrentLocation++; \
15761 (Irp)->Tail.Overlay.CurrentStackLocation++;
And this is what i have in my NT4 sample filter driver,
Irp->CurrentLocation++;
Irp->Tail.Overlay.CurrentStackLocation++;
Same right??? Thought so. Maybe you didn’t see my sample code or
maybe you didn’t know i’m on NT4 DDK platform.
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Curless, Jeffrey”
Sent by: xxxxx@lists.osr.com
05/14/2004 01:57 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
Yes that looks like a problem to me. Are you using the
IoSkipCurrentIrpStackLocation
macro to skip the stack location? Or are you doing it manually. You
should
always use the macros when fiddling with IRP stack locations.
-Jeff
-----Original Message-----
From: xxxxx@deadlinemavens.dtdns.net [mailto:xxxxx@deadlinemavens.dtdns.net]
Sent: Thursday, May 13, 2004 5:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP is passed down - simple passthru filter driver included
So my understanding is that a filter driver that doesn’t add any
completion routine and all that does is passing on the IRP to next guy
down, should do this incrementing of stack location so that the next lower
driver sees the correct I/O stack intended for it by upper-level driver,
eg. ASPI32.SYS which sits on top of my filter driver.
So i believe i’m doing everything that should be done to not mess up the
I/O stack.
However the problem is, if IRP has data transfer request (eg. SCSI READ,
WRITE, INQUIRY) then that leads to crash. But if IRP does not data
transfer, eg. SCSI TEST UNIT READY, START STOP UNIT, then the command is
processed just fine and no crash.
Just bizzare… I’m just almost point of having no hair…
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Curless, Jeffrey”
Sent by: xxxxx@lists.osr.com
05/13/2004 02:34 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash
only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
It would, but he is hand incrementing the stack location… so I think
that might bypass the check.
-Jeff
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 13, 2004 3:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP
is passed down - simple passthru filter driver included
I thought that produce the ‘no more irp stack locations’ bugcheck, but it
does seem to be the obvious cause of the problem.
=====================
Mark Roddy
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, May 13, 2004 3:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP
is passed down - simple passthru filter driver included
Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
64k text>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello, what a Friday it was this past week. With help from
Microsoft DDK support engineer providing me a snippet of source
code from SCSIPORT’s ScsiPortStartIo routine, i was able to
correlate that with the routine’s disassembly, identifying the
exactly assembly instruction that lead to page fault.
Turns out the page fault was caused from NULLPTR deference of
IRP’s MdlAddress member, when ScsiPortStartIo was executing
instructions as part of MmGetMdlVirtualAddress macro.
This being my first Win32 device driver, i neglected to check the
validity of MdlAddress in IRP that my filter driver dispatch receives
from I/O Manager. And sure enough in my dispatch routine the IRP
passed on my I/O Manager had MdlAddress that’s zero value.
So how could that happen? How could I/O Manager pass IRP to me with
MdlAddress that contained zero value? Is I/O Manager broken? I
don’t think so. And i know that if my filter driver is not present
the IRP that gets eventually sent to SCSIPORT has valid MdlAddress
value that whose internal IRP was originated at ASPI32.SYS driver.
So is ASPI32.SYS broken when my filter driver is present where it
sends down bogus MdlAddress in its IRP? I didn’t think so.
So i started to scrutinize my DriverEntry to see if my unnamed
device object i create for this filter driver is anyway different
from other filter driver of same kind. And indeed there was.
I wasn’t setting the Flags field of my device object with the
flag DO_DIRECT_IO. How did i find this out? Besides looking at
other filter drivers, the answer really got to me of course
from OSR book!!! Where else!!! THIS OSR NT4 device driver book
IS THE BIBLE!!! I just wished OSR comes out with newer version
that supports Windows 2000/XP (my next assignment is to come
up with similar SCSIPORT filter driver for Windows 2000/XP and
i’m reading up on this FDO, PDO, bus filter driver, mumble
jumble). The section on Describing Data Buffers on page 188,
it states that Direct I/O is described by this structure called
MDL. So, I/O Manager must be looking at the Flags member of
my Device Object and if the flag doesn’t have the DO_DIRECT_IO
flag set, then I/O Manager must be zeroing out this MdlAddress
from the IRP before passing it on to my dispatch. Hence thinking
MdlAddress member has some sort of relevance with the Direct I/O
after OR’ing the DO_DIRECT_IO flag, my dispatch gets IRP from
I/O Manager that has good MdlAddress value. Cool!!!
So that was it, not a IRP stack problem or anything like that
but rather a solution that required going back to the real
basic, like setting up the device object correctly in the DriverEntry
routine.
Thanks all!!!
Regards,
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
xxxxx@deadlinemavens.com
Sent by: xxxxx@lists.osr.com
05/16/2004 09:46 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
> You should
> always use the macros when fiddling with IRP stack locations.
>
Yes, agreed but that macro isn’t available on NT4 DDK, so i’m doing
it manually however the net effect is the same.
This is what the IoSkipCurrentIrpStackLocation macro is in Windows
2000/XP DDK (ntddk.h for both w2k and wxp),
15732 //++
15733 //
15734 // VOID
15735 // IoSkipCurrentIrpStackLocation (
15736 // IN PIRP Irp
15737 // )
15738 //
15739 // Routine Description:
15740 //
15741 // This routine is invoked to increment the current stack
location of
15742 // a given IRP.
15743 //
15744 // If the caller wishes to call the next driver in a stack,
and does not
15745 // wish to change the arguments, nor does he wish to set a
completion
15746 // routine, then the caller first calls
IoSkipCurrentIrpStackLocation
15747 // and the calls IoCallDriver.
15748 //
15749 // Arguments:
15750 //
15751 // Irp - Pointer to the I/O Request Packet.
15752 //
15753 // Return Value:
15754 //
15755 // None
15756 //
15757 //–
15758
15759 #define IoSkipCurrentIrpStackLocation( Irp ) <br> 15760 (Irp)->CurrentLocation++; <br> 15761 (Irp)->Tail.Overlay.CurrentStackLocation++;
And this is what i have in my NT4 sample filter driver,
Irp->CurrentLocation++;
Irp->Tail.Overlay.CurrentStackLocation++;
Same right??? Thought so. Maybe you didn’t see my sample code or
maybe you didn’t know i’m on NT4 DDK platform.
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Curless, Jeffrey”
Sent by: xxxxx@lists.osr.com
05/14/2004 01:57 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash
only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
Yes that looks like a problem to me. Are you using the
IoSkipCurrentIrpStackLocation
macro to skip the stack location? Or are you doing it manually. You
should
always use the macros when fiddling with IRP stack locations.
-Jeff
-----Original Message-----
From: xxxxx@deadlinemavens.dtdns.net
[mailto:xxxxx@deadlinemavens.dtdns.net]
Sent: Thursday, May 13, 2004 5:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP is passed down - simple passthru filter driver included
So my understanding is that a filter driver that doesn’t add any
completion routine and all that does is passing on the IRP to next guy
down, should do this incrementing of stack location so that the next lower
driver sees the correct I/O stack intended for it by upper-level driver,
eg. ASPI32.SYS which sits on top of my filter driver.
So i believe i’m doing everything that should be done to not mess up the
I/O stack.
However the problem is, if IRP has data transfer request (eg. SCSI READ,
WRITE, INQUIRY) then that leads to crash. But if IRP does not data
transfer, eg. SCSI TEST UNIT READY, START STOP UNIT, then the command is
processed just fine and no crash.
Just bizzare… I’m just almost point of having no hair…
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Curless, Jeffrey”
Sent by: xxxxx@lists.osr.com
05/13/2004 02:34 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash
only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
It would, but he is hand incrementing the stack location… so I think
that might bypass the check.
-Jeff
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 13, 2004 3:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP
is passed down - simple passthru filter driver included
I thought that produce the ‘no more irp stack locations’ bugcheck, but it
does seem to be the obvious cause of the problem.
=====================
Mark Roddy
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, May 13, 2004 3:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S
YS IRP
is passed down - simple passthru filter driver included
Silly question, but have you checked to make sure the IRP has enough stack
locations for the number of drivers in the stack?
-Jeff
64k text>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> So how could that happen? How could I/O Manager pass IRP to me with
MdlAddress that contained zero value?
Yes, if you have a data transfer length of 0.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>> So how could that happen? How could I/O Manager pass IRP to me with
> MdlAddress that contained zero value?
>
Yes, if you have a data transfer length of 0.
Yup, as well as if your device object’s flag is DO_DIRECT_IO not set.
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Maxim S. Shatskih”
Sent by: xxxxx@lists.osr.com
05/16/2004 10:48 PM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: Re: [ntdev] NT4.0 SCSIPORT filter driver crash only when ASPI32.S YS IRP
is passed down - simple passthru filter driver included
> So how could that happen? How could I/O Manager pass IRP to me with
> MdlAddress that contained zero value?
Yes, if you have a data transfer length of 0.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Most likely you haven’t gotten to the root cause at all. As stated, your
tests fail ONLY if your filter is present, and pass if your filter is not
present. The NULL MdlAddress should happen, if as you say your filter is not
modifying the IRP, regardless of your filter presence or absence.
Are you in fact failing to propagate the device object flags correctly?
Do all data transfer operations fail?
(perhaps aspi originates some SRB IRPs on its own, and those are the ones
that have a NULL mdladdress.)
=====================
Mark Roddy
-----Original Message-----
From: xxxxx@deadlinemavens.dtdns.net
[mailto:xxxxx@deadlinemavens.dtdns.net]
Sent: Monday, May 17, 2004 1:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NT4.0 SCSIPORT filter driver crash only
when ASPI32.S YS IRP is passed down - simple passthru filter
driver included>> So how could that happen? How could I/O Manager pass IRP
to me with
>> MdlAddress that contained zero value?
>>
> Yes, if you have a data transfer length of 0.
>
Yup, as well as if your device object’s flag is DO_DIRECT_IO not set.-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Maxim S. Shatskih” Sent by:
> xxxxx@lists.osr.com
> 05/16/2004 10:48 PM
> Please respond to “Windows System Software Devs Interest List”
>
>
> To: “Windows System Software Devs Interest List”
>
> cc:
> Subject: Re: [ntdev] NT4.0 SCSIPORT filter
> driver crash only when ASPI32.S YS IRP
> is passed down - simple passthru filter driver included
>
>
> > So how could that happen? How could I/O Manager pass IRP
> to me with
> > MdlAddress that contained zero value?
>
> Yes, if you have a data transfer length of 0.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@deadlinemavens.com To unsubscribe send a blank email
> to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
Oh never mind, I followed the thread a bit deeper down and saw that indeed
all data transfer requests are failing.
=====================
Mark Roddy
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Monday, May 17, 2004 8:55 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only
when ASPI32.S YS IRP is passed down - simple passthru filter
driver includedMost likely you haven’t gotten to the root cause at all. As
stated, your tests fail ONLY if your filter is present, and
pass if your filter is not present. The NULL MdlAddress
should happen, if as you say your filter is not modifying the
IRP, regardless of your filter presence or absence.Are you in fact failing to propagate the device object flags
correctly?Do all data transfer operations fail?
(perhaps aspi originates some SRB IRPs on its own, and those
are the ones that have a NULL mdladdress.)=====================
Mark Roddy> -----Original Message-----
> From: xxxxx@deadlinemavens.dtdns.net
> [mailto:xxxxx@deadlinemavens.dtdns.net]
> Sent: Monday, May 17, 2004 1:13 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] NT4.0 SCSIPORT filter driver crash only when
> ASPI32.S YS IRP is passed down - simple passthru filter driver
> included
>
> >> So how could that happen? How could I/O Manager pass IRP
> to me with
> >> MdlAddress that contained zero value?
> >>
> > Yes, if you have a data transfer length of 0.
> >
> Yup, as well as if your device object’s flag is
DO_DIRECT_IO not set.
>
> -gshin
>
>
012345678901234567890123456789012345678901234567890123456789012345678
>
>
>
>
>
> “Maxim S. Shatskih” Sent by:
> > xxxxx@lists.osr.com
> > 05/16/2004 10:48 PM
> > Please respond to “Windows System Software Devs Interest List”
> >
> >
> > To: “Windows System Software Devs Interest List”
> >
> > cc:
> > Subject: Re: [ntdev] NT4.0 SCSIPORT filter
> > driver crash only when ASPI32.S YS IRP is passed down - simple
> > passthru filter driver included
> >
> >
> > > So how could that happen? How could I/O Manager pass IRP
> > to me with
> > > MdlAddress that contained zero value?
> >
> > Yes, if you have a data transfer length of 0.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@deadlinemavens.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
This is good detective work.
I’d like to add, however, that what you’re doing in NT4 is basically PnP as
in Win2K and later, and for that the bible is Walter Oney’s book. On pages
780-781 of “Programming the Microsoft Windows Driver Model,” second edition,
he shows how to duplicate certain fields of the device object to which a
filter driver is attaching. In brief, a filter driver shouldn’t blindly turn
on DO_DIRECT_IO (and other things); rather, it should copy the value from
the lower device object. That ensures a uniform stack, up and including the
current filter driver. (MDSN Help, in
ms-help://MS.MSDNQTR.2004APR.1033/kmarch/hh/kmarch/devobjts_8zdz.htm, says
essentially the same thing.)
Not that it would have helped you, but Driver Verifier will bugcheck with
DRIVER_VERIFIER_IOMANAGER_VIOLATION (0x000000C9), parm1 = 0x244, if a filter
driver fails to follow this practice.
–
James Antognini
Windows DDK Support
This posting is provided “AS IS” with no warranties, and confers no rights.
wrote in message news:xxxxx@ntdev…
> Hello, what a Friday it was this past week. With help from
> Microsoft DDK support engineer providing me a snippet of source
> code from SCSIPORT’s ScsiPortStartIo routine, i was able to
> correlate that with the routine’s disassembly, identifying the
> exactly assembly instruction that lead to page fault.
>
> Turns out the page fault was caused from NULLPTR deference of
> IRP’s MdlAddress member, when ScsiPortStartIo was executing
> instructions as part of MmGetMdlVirtualAddress macro.
>
> This being my first Win32 device driver, i neglected to check the
> validity of MdlAddress in IRP that my filter driver dispatch receives
> from I/O Manager. And sure enough in my dispatch routine the IRP
> passed on my I/O Manager had MdlAddress that’s zero value.
>
> So how could that happen? How could I/O Manager pass IRP to me with
> MdlAddress that contained zero value? Is I/O Manager broken? I
> don’t think so. And i know that if my filter driver is not present
> the IRP that gets eventually sent to SCSIPORT has valid MdlAddress
> value that whose internal IRP was originated at ASPI32.SYS driver.
>
> So is ASPI32.SYS broken when my filter driver is present where it
> sends down bogus MdlAddress in its IRP? I didn’t think so.
>
> So i started to scrutinize my DriverEntry to see if my unnamed
> device object i create for this filter driver is anyway different
> from other filter driver of same kind. And indeed there was.
> I wasn’t setting the Flags field of my device object with the
> flag DO_DIRECT_IO. How did i find this out? Besides looking at
> other filter drivers, the answer really got to me of course
> from OSR book!!! Where else!!! THIS OSR NT4 device driver book
> IS THE BIBLE!!! I just wished OSR comes out with newer version
> that supports Windows 2000/XP (my next assignment is to come
> up with similar SCSIPORT filter driver for Windows 2000/XP and
> i’m reading up on this FDO, PDO, bus filter driver, mumble
> jumble). The section on Describing Data Buffers on page 188,
> it states that Direct I/O is described by this structure called
> MDL. So, I/O Manager must be looking at the Flags member of
> my Device Object and if the flag doesn’t have the DO_DIRECT_IO
> flag set, then I/O Manager must be zeroing out this MdlAddress
> from the IRP before passing it on to my dispatch. Hence thinking
> MdlAddress member has some sort of relevance with the Direct I/O
> after OR’ing the DO_DIRECT_IO flag, my dispatch gets IRP from
> I/O Manager that has good MdlAddress value. Cool!!!
>
> So that was it, not a IRP stack problem or anything like that
> but rather a solution that required going back to the real
> basic, like setting up the device object correctly in the DriverEntry
> routine.
>
> Thanks all!!!
>
> Regards,
>
> -gshin
>
> 012345678901234567890123456789012345678901234567890123456789012345678
> Most likely you haven’t gotten to the root cause at all.
Actually i have. I think the confusion might be that sometimes the
entire message threads a given discussion is not carried in the
e-mail so one might not be getting the whole picture of the discussion
that has been taking place. Gets confusion for me to sometimes.
As stated, your
tests fail ONLY if your filter is present, and pass if your filter
is not present.
Yes, that was the case early in the testing. Filter driver always
gets the blame, because as you said, “it works without it but doesn’t
with it”. Filter drivers gets all the blame… 
Hey, but that’s
what makes it so much more challenging and fun to write.
The NULL MdlAddress should happen, if as you say your filter is not
modifying the IRP, regardless of your filter presence or absence.
No. The NULL MdlAddress wasn’t happening without my filter in
presence, and i verified that by using this cool little tool called
Device Filter v2.2 from www.ntkernel.com site.
Are you in fact failing to propagate the device object flags
correctly?
Yup, that was my problem hence problem has been root caused. I was
failing to OR my device object flag with DO_DIRECT_IO. Something
i’ll remember for a long time!!!
Do all data transfer operations fail?
Yup, as you later found out. That was the clue i was hanging on to
but i was so focused in something else, but eventually the
disassembly of ScsiPortStartIo routine in SCSIPORT source lead to
the solution.
(perhaps aspi originates some SRB IRPs on its own, and those are the
ones that have a NULL mdladdress.
So ASPI32.SYS generates internal IRP and depending on the transfer
length specified in the ASPI’s own SRB structure, the IRP passed
down to SCSIPORT has MdlAddress that is either NULL (for no data
transfer) or valid address for data transfers.
Thanks much,
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Roddy, Mark”
Sent by: xxxxx@lists.osr.com
05/17/2004 06:54 AM
Please respond to “Windows System Software Devs Interest List”
To: “Windows System Software Devs Interest List”
cc:
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only when
ASPI32.S YS IRP is passed down - simple passthru filter driver included
Most likely you haven’t gotten to the root cause at all. As stated, your
tests fail ONLY if your filter is present, and pass if your filter is
not
present. The NULL MdlAddress should happen, if as you say your filter is
not
modifying the IRP, regardless of your filter presence or absence.
Are you in fact failing to propagate the device object flags correctly?
Do all data transfer operations fail?
(perhaps aspi originates some SRB IRPs on its own, and those are the
ones
that have a NULL mdladdress.)
=====================
Mark Roddy
> -----Original Message-----
> From: xxxxx@deadlinemavens.dtdns.net
> [mailto:xxxxx@deadlinemavens.dtdns.net]
> Sent: Monday, May 17, 2004 1:13 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] NT4.0 SCSIPORT filter driver crash only
> when ASPI32.S YS IRP is passed down - simple passthru filter
> driver included
>
> >> So how could that happen? How could I/O Manager pass IRP
> to me with
> >> MdlAddress that contained zero value?
> >>
> > Yes, if you have a data transfer length of 0.
> >
> Yup, as well as if your device object’s flag is DO_DIRECT_IO not set.
>
> -gshin
>
> 012345678901234567890123456789012345678901234567890123456789012345678
>
>
>
>
>
> “Maxim S. Shatskih” Sent by:
> xxxxx@lists.osr.com
> 05/16/2004 10:48 PM
> Please respond to “Windows System Software Devs Interest List”
>
>
> To: “Windows System Software Devs Interest List”
>
> cc:
> Subject: Re: [ntdev] NT4.0 SCSIPORT filter
> driver crash only when ASPI32.S YS IRP
> is passed down - simple passthru filter driver included
>
>
> > So how could that happen? How could I/O Manager pass IRP
> to me with
> > MdlAddress that contained zero value?
>
> Yes, if you have a data transfer length of 0.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@deadlinemavens.com To unsubscribe send a blank email
> to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@deadlinemavens.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
George Shin
EVA Firmware Development Engineer
Online Storage Division - Boise, Idaho
Network Storage Solutions
Hewlett-Packard Company
208-396-4801 (work)
george.shin@hp.com
012345678901234567890123456789012345678901234567890123456789012345678
DSS/Diffie-Hellman Key
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0i for non-commercial use
mQGiBDY678URBADcwE2rJwU4H/uUOrOL/19dtB8Wz8kEGbu+ODM/OfW9xe1AYM/5
aeNyF3Ngt3m2MFTGqCKCV/HmyezMupo9Oy6MpKGdmaBnM1vke+ReZn6aN9bhxiqF
8YO9b6zwpeNUxHrTmAy21DEJsTHdlH0fEvqM4v8v6n4uAD0Qa5rAu/BQgwCg/5EK
2VUvrdEKt9Jg5ZvjDF1cNwMD/ip/cbQbu8fm2C2sX4SUNIItH47GStd+6t9u5imY
C8ypo3CvVg==
=mTPj
-----END PGP PUBLIC KEY BLOCK-----
Yeah - see my later post. My fault for not reading the entire thread.
=====================
Mark Roddy
-----Original Message-----
From: George Shin [mailto:xxxxx@deadlinemavens.dtdns.net]
Sent: Monday, May 17, 2004 6:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NT4.0 SCSIPORT filter driver crash only
when ASPI32.S YS IRP is passed down - simple passthru filter
driver included> Most likely you haven’t gotten to the root cause at all.
>
Actually i have. I think the confusion might be that
sometimes the entire message threads a given discussion is
not carried in the e-mail so one might not be getting the
whole picture of the discussion that has been taking place.
Gets confusion for me to sometimes.> As stated, your
> tests fail ONLY if your filter is present, and pass if your
filter is
> not present.
>
Yes, that was the case early in the testing. Filter driver
always gets the blame, because as you said, “it works without
it but doesn’t with it”. Filter drivers gets all the
blame…
challenging and fun to write.> The NULL MdlAddress should happen, if as you say your filter is not
> modifying the IRP, regardless of your filter presence or absence.
>
No. The NULL MdlAddress wasn’t happening without my filter
in presence, and i verified that by using this cool little
tool called Device Filter v2.2 from www.ntkernel.com site.> Are you in fact failing to propagate the device object flags
> correctly?
>
Yup, that was my problem hence problem has been root caused.
I was failing to OR my device object flag with DO_DIRECT_IO.
Something i’ll remember for a long time!!!
> Do all data transfer operations fail?
>
Yup, as you later found out. That was the clue i was hanging
on to but i was so focused in something else, but eventually
the disassembly of ScsiPortStartIo routine in SCSIPORT source
lead to the solution.> (perhaps aspi originates some SRB IRPs on its own, and
those are the
> ones that have a NULL mdladdress.
>
So ASPI32.SYS generates internal IRP and depending on the
transfer length specified in the ASPI’s own SRB structure,
the IRP passed down to SCSIPORT has MdlAddress that is either
NULL (for no data
transfer) or valid address for data transfers.Thanks much,
-gshin
012345678901234567890123456789012345678901234567890123456789012345678
“Roddy, Mark”
> Sent by: xxxxx@lists.osr.com
> 05/17/2004 06:54 AM
> Please respond to “Windows System Software Devs Interest List”
>
> To: “Windows System Software Devs Interest List”
>
> cc:
> Subject: RE: [ntdev] NT4.0 SCSIPORT filter
> driver crash only when ASPI32.S YS IRP is passed down -
> simple passthru filter driver included
>
>
> Most likely you haven’t gotten to the root cause at all. As
> stated, your tests fail ONLY if your filter is present, and
> pass if your filter is not present. The NULL MdlAddress
> should happen, if as you say your filter is not modifying the
> IRP, regardless of your filter presence or absence.
>
> Are you in fact failing to propagate the device object flags
> correctly?
>
> Do all data transfer operations fail?
>
> (perhaps aspi originates some SRB IRPs on its own, and those
> are the ones that have a NULL mdladdress.)
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: xxxxx@deadlinemavens.dtdns.net
> > [mailto:xxxxx@deadlinemavens.dtdns.net]
> > Sent: Monday, May 17, 2004 1:13 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] NT4.0 SCSIPORT filter driver crash only when
> > ASPI32.S YS IRP is passed down - simple passthru filter driver
> > included
> >
> > >> So how could that happen? How could I/O Manager pass IRP
> > to me with
> > >> MdlAddress that contained zero value?
> > >>
> > > Yes, if you have a data transfer length of 0.
> > >
> > Yup, as well as if your device object’s flag is
> DO_DIRECT_IO not set.
> >
> > -gshin
> >
> >
> 012345678901234567890123456789012345678901234567890123456789012345678
> >
> >
> >
> >
> >
> > “Maxim S. Shatskih” Sent by:
> > xxxxx@lists.osr.com
> > 05/16/2004 10:48 PM
> > Please respond to “Windows System Software Devs Interest List”
> >
> >
> > To: “Windows System Software Devs Interest List”
> >
> > cc:
> > Subject: Re: [ntdev] NT4.0 SCSIPORT filter
> > driver crash only when ASPI32.S YS IRP is passed down - simple
> > passthru filter driver included
> >
> >
> > > So how could that happen? How could I/O Manager pass IRP
> > to me with
> > > MdlAddress that contained zero value?
> >
> > Yes, if you have a data transfer length of 0.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@deadlinemavens.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@deadlinemavens.com To unsubscribe send a blank email
> to xxxxx@lists.osr.com
>
>
> –
> George Shin
> EVA Firmware Development Engineer
> Online Storage Division - Boise, Idaho
> Network Storage Solutions
> Hewlett-Packard Company
> 208-396-4801 (work)
> george.shin@hp.com
>
> 012345678901234567890123456789012345678901234567890123456789012345678
> DSS/Diffie-Hellman Key
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: PGPfreeware 5.0i for non-commercial use
>
> mQGiBDY678URBADcwE2rJwU4H/uUOrOL/19dtB8Wz8kEGbu+ODM/OfW9xe1AYM/5
> aeNyF3Ngt3m2MFTGqCKCV/HmyezMupo9Oy6MpKGdmaBnM1vke+ReZn6aN9bhxiqF
> 8YO9b6zwpeNUxHrTmAy21DEJsTHdlH0fEvqM4v8v6n4uAD0Qa5rAu/BQgwCg/5EK
> 2VUvrdEKt9Jg5ZvjDF1cNwMD/ip/cbQbu8fm2C2sX4SUNIItH47GStd+6t9u5imY
> C8ypo3CvVg==
> =mTPj
> -----END PGP PUBLIC KEY BLOCK-----
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>