invalid address

NTDEV
1

Hi,

I’m fairly new at writing kernel mode drivers so please bare with me. I’m
writing an NT4 style driver (because I saw some good examples in the OSR
book) and I am required to do driver queueing because I can have
simultaneous reads and writes to a PCI card I’m writing the driver for. I’m
using DeviceIoControl in the user app for reads/writes because I need to
specify a DDR address on the PCI card and, of course, a buffer in the user
area. The part of my driver that has to access the BAR0 regs (read/write)
works just fine.

My problem revolves around the queueing of IRPs. In my StartReadIrp code,
where I’m deciding whether an IRP should be queued (or canceled) I have a
spinlock set (so I’m at dispatch_level) and when I get to the code to
determine how may map regs I get ( first calling pMdlVirtualAddress =
MmGetMdlVirtualAddress(Irp->MdlAddress)), I get a violation on the call.
Turns out the Irp->MdlAddress is 0x00000000. Does anyone have any idea what
could cause this? I’m using METHOD_OUT_DIRECT for the IOCTL. Any help would
be appreciated.

Thanks in advance,

Howard Kellerp.s. I also posted this at msdn

2

Well if you are targeting w2k or later your driver really ought to be a pnp
driver not an NT4 legacy driver. But I’ll let that pass for now, as it is
not related to your problem.

How exactly are you calling DeviceIoControl? Specifically what is the length
that you specify for output buffer?

=====================
Mark Roddy

-----Original Message-----
From: hkeller [mailto:xxxxx@memecdesign.com]
Sent: Monday, February 09, 2004 4:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] invalid address

Hi,

I’m fairly new at writing kernel mode drivers so please bare
with me. I’m writing an NT4 style driver (because I saw some
good examples in the OSR
book) and I am required to do driver queueing because I can
have simultaneous reads and writes to a PCI card I’m writing
the driver for. I’m using DeviceIoControl in the user app for
reads/writes because I need to specify a DDR address on the
PCI card and, of course, a buffer in the user area. The part
of my driver that has to access the BAR0 regs (read/write)
works just fine.

My problem revolves around the queueing of IRPs. In my
StartReadIrp code, where I’m deciding whether an IRP should
be queued (or canceled) I have a spinlock set (so I’m at
dispatch_level) and when I get to the code to determine how
may map regs I get ( first calling pMdlVirtualAddress =
MmGetMdlVirtualAddress(Irp->MdlAddress)), I get a violation
on the call.
Turns out the Irp->MdlAddress is 0x00000000. Does anyone have
any idea what could cause this? I’m using METHOD_OUT_DIRECT
for the IOCTL. Any help would be appreciated.

Thanks in advance,

Howard Kellerp.s. I also posted this at msdn

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

3

is the client a user-mode application or another kernel driver?

if the former, are you sure you supplied a buffer to the OutputBuffer
parameter and a non-zero length (DeviceIoControl takes a lot of
parameters and I’ve screwed this up occasioanlly).

if the latter did the client driver actually store an MDL into
MdlAddress? IoCallDriver doesn’t do this for you (though
IoBuildDeviceIoControlRequest would).

did the IRP have a valid MdlAdresss when your dispatch routine was
called? Perhaps you’ve managed to overwrite it somehow (remember it’s
in a union with several other fields). If it’s valid when you get the
irp you can set a write breakpoint in the debugger on &(Irp->MdlAddress)
and see what code is clearing it.

on a design note - why are you holding a spinlock while computing the
number of map registers that you need? That number won’t change out
from under you so you don’t need the lock there. You want to get into
the practice of only holding locks while you’re protecting a shared
resource, not while you’re doing drudge work. Do the drudge work up
front.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Monday, February 09, 2004 1:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] invalid address

Hi,

I’m fairly new at writing kernel mode drivers so please bare with me.
I’m writing an NT4 style driver (because I saw some good examples in the
OSR
book) and I am required to do driver queueing because I can have
simultaneous reads and writes to a PCI card I’m writing the driver for.
I’m using DeviceIoControl in the user app for reads/writes because I
need to specify a DDR address on the PCI card and, of course, a buffer
in the user area. The part of my driver that has to access the BAR0
regs (read/write) works just fine.

My problem revolves around the queueing of IRPs. In my StartReadIrp
code, where I’m deciding whether an IRP should be queued (or canceled) I
have a spinlock set (so I’m at dispatch_level) and when I get to the
code to determine how may map regs I get ( first calling
pMdlVirtualAddress = MmGetMdlVirtualAddress(Irp->MdlAddress)), I get a
violation on the call.
Turns out the Irp->MdlAddress is 0x00000000. Does anyone have any idea
what could cause this? I’m using METHOD_OUT_DIRECT for the IOCTL. Any
help would be appreciated.

Thanks in advance,

Howard Kellerp.s. I also posted this at msdn

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

ignore the part about the MdlAddress sharing a storage location - I got
it confused with SystemBuffer. Still I’d check to see if it’s valid
when you get the request as that would tell you whether you have a data
corruptor (or perhaps that you’re freeing or completing the IRP before
processing it)

I presume that at the pont you’re making this calculation you either
haven’t returned from your dispatch routine or you have returned
STATUS_PENDING?

-p

-----Original Message-----
From: Peter Wieland
Sent: Monday, February 09, 2004 1:33 PM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] invalid address

is the client a user-mode application or another kernel driver?

if the former, are you sure you supplied a buffer to the OutputBuffer
parameter and a non-zero length (DeviceIoControl takes a lot of
parameters and I’ve screwed this up occasioanlly).

if the latter did the client driver actually store an MDL into
MdlAddress? IoCallDriver doesn’t do this for you (though
IoBuildDeviceIoControlRequest would).

did the IRP have a valid MdlAdresss when your dispatch routine was
called? Perhaps you’ve managed to overwrite it somehow (remember it’s
in a union with several other fields). If it’s valid when you get the
irp you can set a write breakpoint in the debugger on &(Irp->MdlAddress)
and see what code is clearing it.

on a design note - why are you holding a spinlock while computing the
number of map registers that you need? That number won’t change out
from under you so you don’t need the lock there. You want to get into
the practice of only holding locks while you’re protecting a shared
resource, not while you’re doing drudge work. Do the drudge work up
front.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Monday, February 09, 2004 1:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] invalid address

Hi,

I’m fairly new at writing kernel mode drivers so please bare with me.
I’m writing an NT4 style driver (because I saw some good examples in the
OSR
book) and I am required to do driver queueing because I can have
simultaneous reads and writes to a PCI card I’m writing the driver for.
I’m using DeviceIoControl in the user app for reads/writes because I
need to specify a DDR address on the PCI card and, of course, a buffer
in the user area. The part of my driver that has to access the BAR0
regs (read/write) works just fine.

My problem revolves around the queueing of IRPs. In my StartReadIrp
code, where I’m deciding whether an IRP should be queued (or canceled) I
have a spinlock set (so I’m at dispatch_level) and when I get to the
code to determine how may map regs I get ( first calling
pMdlVirtualAddress = MmGetMdlVirtualAddress(Irp->MdlAddress)), I get a
violation on the call.
Turns out the Irp->MdlAddress is 0x00000000. Does anyone have any idea
what could cause this? I’m using METHOD_OUT_DIRECT for the IOCTL. Any
help would be appreciated.

Thanks in advance,

Howard Kellerp.s. I also posted this at msdn

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Thanks for getting back to me Mark,

It’s one of those situations where I had very little time for schedule.

In any case,

sizeof(ddr_data),
where unsigned char ddr_data[8];

I really wanted to use a longlong, but good old VC++ 6.0 didn’t seem to like
that

Howard

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
> Well if you are targeting w2k or later your driver really ought to be a
pnp
> driver not an NT4 legacy driver. But I’ll let that pass for now, as it is
> not related to your problem.
>
> How exactly are you calling DeviceIoControl? Specifically what is the
length
> that you specify for output buffer?
>
>
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: hkeller [mailto:xxxxx@memecdesign.com]
> > Sent: Monday, February 09, 2004 4:14 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] invalid address
> >
> > Hi,
> >
> > I’m fairly new at writing kernel mode drivers so please bare
> > with me. I’m writing an NT4 style driver (because I saw some
> > good examples in the OSR
> > book) and I am required to do driver queueing because I can
> > have simultaneous reads and writes to a PCI card I’m writing
> > the driver for. I’m using DeviceIoControl in the user app for
> > reads/writes because I need to specify a DDR address on the
> > PCI card and, of course, a buffer in the user area. The part
> > of my driver that has to access the BAR0 regs (read/write)
> > works just fine.
> >
> > My problem revolves around the queueing of IRPs. In my
> > StartReadIrp code, where I’m deciding whether an IRP should
> > be queued (or canceled) I have a spinlock set (so I’m at
> > dispatch_level) and when I get to the code to determine how
> > may map regs I get ( first calling pMdlVirtualAddress =
> > MmGetMdlVirtualAddress(Irp->MdlAddress)), I get a violation
> > on the call.
> > Turns out the Irp->MdlAddress is 0x00000000. Does anyone have
> > any idea what could cause this? I’m using METHOD_OUT_DIRECT
> > for the IOCTL. Any help would be appreciated.
> >
> > Thanks in advance,
> >
> > Howard Kellerp.s. I also posted this at msdn
> >
> >
> >
> > —
> > 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
> >
>

6

Hi Peter,

Thanks for getting back to me.

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
ignore the part about the MdlAddress sharing a storage location - I got
it confused with SystemBuffer. Still I’d check to see if it’s valid
when you get the request as that would tell you whether you have a data
corruptor (or perhaps that you’re freeing or completing the IRP before
processing it)

I presume that at the pont you’re making this calculation you either
haven’t returned from your dispatch routine or you have returned
STATUS_PENDING?
>>>>>>>> Iv’e based my code on the DMA example in the back of the OSR book
since it seemed to do all that I needed to do. The spin lock was opened when
I started to process the read IRP I received in my IOCTL dispatch routine. I
had just determined that there was no outstanding read IRP being processed,
so (as in the example code) I was the code that determined if I had enough
map registers to complete the request in one pass or not. If I determined
that the IRP needed to be queued, I would add the IRP to my read queue
(hence the spinlock being active). In this case, I would have gone all the
way through IoAllocateAdapterChannel prior to releasing the spin lock. I
then return STATUS_PENDING. (I had marked the IRP pending previously)

And I have had so much fun with windbg

-p

-----Original Message-----
From: Peter Wieland
Sent: Monday, February 09, 2004 1:33 PM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] invalid address

is the client a user-mode application or another kernel driver?

if the former, are you sure you supplied a buffer to the OutputBuffer
parameter and a non-zero length (DeviceIoControl takes a lot of
parameters and I’ve screwed this up occasioanlly).

if the latter did the client driver actually store an MDL into
MdlAddress? IoCallDriver doesn’t do this for you (though
IoBuildDeviceIoControlRequest would).

did the IRP have a valid MdlAdresss when your dispatch routine was
called? Perhaps you’ve managed to overwrite it somehow (remember it’s
in a union with several other fields). If it’s valid when you get the
irp you can set a write breakpoint in the debugger on &(Irp->MdlAddress)
and see what code is clearing it.

on a design note - why are you holding a spinlock while computing the
number of map registers that you need? That number won’t change out
from under you so you don’t need the lock there. You want to get into
the practice of only holding locks while you’re protecting a shared
resource, not while you’re doing drudge work. Do the drudge work up
front.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Monday, February 09, 2004 1:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] invalid address

Hi,

I’m fairly new at writing kernel mode drivers so please bare with me.
I’m writing an NT4 style driver (because I saw some good examples in the
OSR
book) and I am required to do driver queueing because I can have
simultaneous reads and writes to a PCI card I’m writing the driver for.
I’m using DeviceIoControl in the user app for reads/writes because I
need to specify a DDR address on the PCI card and, of course, a buffer
in the user area. The part of my driver that has to access the BAR0
regs (read/write) works just fine.

My problem revolves around the queueing of IRPs. In my StartReadIrp
code, where I’m deciding whether an IRP should be queued (or canceled) I
have a spinlock set (so I’m at dispatch_level) and when I get to the
code to determine how may map regs I get ( first calling
pMdlVirtualAddress = MmGetMdlVirtualAddress(Irp->MdlAddress)), I get a
violation on the call.
Turns out the Irp->MdlAddress is 0x00000000. Does anyone have any idea
what could cause this? I’m using METHOD_OUT_DIRECT for the IOCTL. Any
help would be appreciated.

Thanks in advance,

Howard Kellerp.s. I also posted this at msdn

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Hi Peter,

Thanks for getting back to me on this.

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
is the client a user-mode application or another kernel driver?
>>>>>>> The client is a user app that interfaces via DeviceIoControl calls
if the former, are you sure you supplied a buffer to the OutputBuffer
parameter and a non-zero length (DeviceIoControl takes a lot of
parameters and I’ve screwed this up occasioanlly).
>>>>>>>> The output buffer was
unsigned char ddr_data[8]; // I wanted to use longlong but VC++6.0 wouldn’t
let me
teh output buffer size was specified as
sizeof(ddr_data)

if the latter did the client driver actually store an MDL into
MdlAddress? IoCallDriver doesn’t do this for you (though
IoBuildDeviceIoControlRequest would).

did the IRP have a valid MdlAdresss when your dispatch routine was
called? Perhaps you’ve managed to overwrite it somehow (remember it’s
in a union with several other fields). If it’s valid when you get the
irp you can set a write breakpoint in the debugger on &(Irp->MdlAddress)
and see what code is clearing it.

>>>>>>Windbg showed an invalid address at Irp->MdlAddress in the local
variables

on a design note - why are you holding a spinlock while computing the
number of map registers that you need? That number won’t change out
from under you so you don’t need the lock there. You want to get into
the practice of only holding locks while you’re protecting a shared
resource, not while you’re doing drudge work. Do the drudge work up
front.

>>>>>> I agree, but I just grabbed an example out of a book that I “assumed”
worked.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Monday, February 09, 2004 1:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] invalid address

Hi,

I’m fairly new at writing kernel mode drivers so please bare with me.
I’m writing an NT4 style driver (because I saw some good examples in the
OSR
book) and I am required to do driver queueing because I can have
simultaneous reads and writes to a PCI card I’m writing the driver for.
I’m using DeviceIoControl in the user app for reads/writes because I
need to specify a DDR address on the PCI card and, of course, a buffer
in the user area. The part of my driver that has to access the BAR0
regs (read/write) works just fine.

My problem revolves around the queueing of IRPs. In my StartReadIrp
code, where I’m deciding whether an IRP should be queued (or canceled) I
have a spinlock set (so I’m at dispatch_level) and when I get to the
code to determine how may map regs I get ( first calling
pMdlVirtualAddress = MmGetMdlVirtualAddress(Irp->MdlAddress)), I get a
violation on the call.
Turns out the Irp->MdlAddress is 0x00000000. Does anyone have any idea
what could cause this? I’m using METHOD_OUT_DIRECT for the IOCTL. Any
help would be appreciated.

Thanks in advance,

Howard Kellerp.s. I also posted this at msdn

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

> I really wanted to use a longlong, but good old VC++ 6.0 didn’t seem to
like

that

typedef longlong __int64;

Loren

Also __int32, __int16, __int8, but I’ve never seen anyone use any of those.