Oh well … it did work that way in NT4 … but I found the problem.
First, I was not using DO_DIRECT_IO, I was using DO_BUFFERED_IO and
Irp->MdlAddress was NULL. With SecondaryBuffer set TRUE, I get an Access
Denied when the MdlAddress is used to store the new MDL pointer. The request
block pointer I pass to Read/WriteFile is now accessed via
MmGetMdlVirtualAddress. Rather logical, actually, but unexpected. Maybe it
should be noted that this behavior is observed from a WDM driver. With
DO_DIRECT_IO, and SecondaryBuffer TRUE IoAllocateMdl sets
Irp->MdlAddress->Next to the new MDL.
A legacy NT4 driver running under 2000, as well as NT4 behaves differently.
NT4 sets the pointer in
Irp->MdlAddress if the Irp->MdlAddress is NULL. The control block pointer is
also found in
Irp->AssociatedIrp.SystemBuffer.
Gary
-----Original Message-----
From: Gary Little [mailto:xxxxx@Broadstor.com]
Sent: Thursday, January 25, 2001 4:17 PM
To: NT Developers Interest List
Subject: [ntdev] [NTDEV] IoAllocateMdl …
Ready for this? It’s another one of those “It works in NT4”
questions.
First, here is what I get in WinDbg:
Access violation - code c0000005 (!!! second chance !!!)
ntkrnlmp!IoAllocateMdl+f5:
8011cfe9 8b10 mov edx,[eax]
This is what I am doing:
PMDL pMdl = IoAllocateMdl(packet->DataBuffer,
packet->Length,
TRUE,
FALSE,
Irp);
__try {
MmProbeAndLockPages(pMdl,
Packet->DataBuffer is a buffer coming up from the user’s
address space with
a length of
packet->Length. I’ve stepped it through the assembly for
IoAllocateMdl and
what I see is that the DataBuffer parameter (0x007d0040)
pushed onto the
stack gets overloaded with A0. This is so simple I cannot
see the problem,
and of course my first thought is “bug in IoAllocateMdl” but
I doubt it.
Gary
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: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com