[newbie] SystemAddressMDLSafe BSOD query

NTDEV
1

Hi Everyone!

I am developing a driver using the msvad samples to start with and I am BSODing with DRIVER_IRQL_NOT_LESS_OR_EQUAL.

This is how my driver works

  1. I send in a set of buffers (say 10) to the driver from my application(through user defined IOCTL) and the driver stores these addresses in a list internally, I used mmGetSystemAddressMDLSafe to get the Kernelmode safe address.
    The driver is filling up these buffers with data (eg: 0xA)

  2. Then I issue an other user defined IOCTL to start reading those same buffers (say buffer #1) from the user space and it BSODs (basically I am expecting all 0xA’s to come)

Can I do this? What am I missing here?
Is this method of storing all the buffer addresses right?
If not then what is the right way to do?

Thanks in advance.

2

Just adding more…
I need to get the data from those buffers Asyncronously… can I use some APC mechanism to pass data back to UserSpace?

3

If you are sending both IOCTLs in context of the same app, then there is no need for MDLs, in the first place - your driver can access memory directly (this is how METHOD_NEITHER works). Certainly, if you do things this way, you have to make sure that memory is valid, and access the buffer only in _TRY block just in case if something gets wrong…

Concerning your question, it would be better if you showed us you code - judging from your description, there may be quite a few things that you have done wrong…

Anton Bassov

4

Hi!!

I am using METHOD_OUT_DIRECT

My APP is simple:
char Buffer[20][1024];
for(i=0 ; i < 20 ; ++i)
{
//will store these addresses inside the buffer - but driver will not fill it still
DrvAddBuffer( Buffer[i] ); //DeviceIoControl - IOCTL_ADD_BUFFER
}
DrvStart(); // DeviceIoControl - IOCTL_START_FILL – now the driver will start to fill (BSOD here)
for( i=0 ;i <20 ;++i)
{
printf(" %s \n", Buffer[i] ); //assuming the driver has filled some data
}

My Driver:
case IOCTL_ADD_BUFFER:
List[i] = mmGetSystemAddressForMDLSafe( pIrp->MDLAddress, …);
++i;
case IOCTL_START_FILL:
Flag = true;

…

…

…
//other funciton
i =0;
if (Flag == true )
{
RtlSetMemory(List[i], 1024, ‘A’);
++i;
}

[all the safe checks for i, List, Buffer is removed for readability]

I am actually trying to do what WaveInXXX calls do… like WaveInAddBuffer and WaveInStart

5

Hi!

But if I use Method_Neither, will the userspace buffer addresses be still locked? (nonpaged)
Or Will it require the driver to lock and then use?

6

Just plain IoCompleteRequest sends them back to user space.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Just adding more…
> I need to get the data from those buffers Asyncronously… can I use some APC
mechanism to pass data back to UserSpace?
>

7

> But if I use Method_Neither, will the userspace buffer addresses be still locked? (nonpaged)

You are missing the point - as long as you access user memory only in context of an app that sends IOCTL (i.e. directly in response to IOCTL) at IRQL< DISPATCH_LEVEL, there is no need for either building MDLs or mapping it to the kernel address space or locking it in RAM.

However, if you are interested in asynch IO, i.e. in accessing it at some point after having returned STATUS_PENDING from your Dispatch() routine, METHOD_NEITHER is just not going to work. Instead, you have to build MDL that describes a buffer, lock it (if you rely upon METHOD_OUT_DIRECT the OS does it for you), and map it into the kernel address space *before* having returned STATUS_PENDING. At some point in the future you will write to the buffer (as described by its kernel address space), and complete IRP

Anton Bassov

8

Exactly… thats my point… I dont want to use IRPs… I just want to store all the buffer addresses at one go and make the driver write to those continuously… which inturn my app will read.

9

How do yuou think you will synchronize the application and the driver? How
will you handle detecting the application going away (crashing or being
terminated)? How will you handle not enough buffer space?

This is an incredibly poor design for a driver, that has been discussed
many times in this forum. Loon for subjects like “event sharing” to see
that this is a bad idea. Unless you are doing extremely fast I/O (i.e.
over 100MB/sec) doing this will just add incredibly to your work, and make
your driver likely to crash. As a newbie you should not be trying this.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Exactly… thats my point… I dont want to use IRPs… I just want to
> store all the buffer addresses at one go and make the driver write to
> those continuously… which inturn my app will read.
>

10

> I dont want to use IRPs… I just want to store all the buffer addresses at one go and make

the driver write to those continuously… which inturn my app will read.

What makes you believe that this is better that “inverted call”??? Don already explained to you the potential issues here, but I am just curious about your motivation - for this or that reason, newbies always want to share a buffer, so that we have to explain the same thing again and again and again…

What makes you belive that such approach can give you anything, apart from extra worries and potential bugs???

Anton Bassov

11

If it’s of any help, as an inexperienced driver developer I originally used
the scheme mentioned, i.e. allocating user memory, passing the pointers to
the driver, then letting the driver write to user memory.

This works fine, after doing all the correct things to lock down the user
memory and access it from the kernel - not major hassles. Synchronisation is
easy too, really, using say circular buffers and and some shared read write
index locations.

I’m also interested to infer from Don’s message that this is a reasonable
idea for very fast transfers (this info filed for future projects).

However I took the advice on this forum to rearrange things as I was nervous
about having the driver happily writing into user memory even if my app
failed. True, if it all works perfectly, the removal of the app should
notify the driver safely but what if I made a mistake with my user
allocation, say I freed the memory by mistake, or some other thing I haven’t
even thought about happened.

So I changed it to let the app allocate all the buffers, and then used the
standard mechanisms for reading and writing user data into the driver. It
didn’t take long to do this and I feel a bit safer. I also feel more in
control of the buffers as they are kernel allocated. I’m not aware of any
perfomance issues.

I did find it useful to add an iocontrol function to inspect the various
realtime parameters in the driver from the app, as these had become
invisible after the change. Being able to monitor the driver working in real
time from the app has been immensely useful and saved a lot of debugging
time…

BTW I have an axiom to propose: whatever method you choose to implement a
driver function, you’ll find out afterwards that it was the wrong method…

Mike

----- Original Message -----
From: Don Burn
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Monday, May 14, 2007 11:04 AM
Subject: Re:[ntdev] [newbie] SystemAddressMDLSafe BSOD query

How do yuou think you will synchronize the application and the driver? How
will you handle detecting the application going away (crashing or being
terminated)? How will you handle not enough buffer space?

This is an incredibly poor design for a driver, that has been discussed
many times in this forum. Loon for subjects like “event sharing” to see
that this is a bad idea. Unless you are doing extremely fast I/O (i.e.
over 100MB/sec) doing this will just add incredibly to your work, and make
your driver likely to crash. As a newbie you should not be trying this.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Exactly… thats my point… I dont want to use IRPs… I just want to
> store all the buffer addresses at one go and make the driver write to
> those continuously… which inturn my app will read.
>

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

12

Ok… got it!!
Synchronizing the application and driver will not be possible…probably
this was all my question. I should have put it rightly.

Thanks for the patient responses.

On 5/14/07, xxxxx@hotmail.com wrote:
>
> > I dont want to use IRPs… I just want to store all the buffer addresses
> at one go and make
> > the driver write to those continuously… which inturn my app will
> read.
>
> What makes you believe that this is better that “inverted call”??? Don
> already explained to you the potential issues here, but I am just curious
> about your motivation - for this or that reason, newbies always want to
> share a buffer, so that we have to explain the same thing again and again
> and again…
>
> What makes you belive that such approach can give you anything, apart from
> extra worries and potential bugs???
>
> Anton Bassov
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

13

Thanks Don for making it clear.

14

Actually all of these things are possible: synchronizing application and
driver and safely sharing large blocks of memory. The problem is that they
(particularly safely sharing memory) are difficult to get right. Further,
other than specific use cases that require huge data rates, safer and
simpler ‘inverted call’ techniques are preferred.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AsHwAtH
Sent: Monday, May 14, 2007 6:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] [newbie] SystemAddressMDLSafe BSOD query

Ok… got it!!
Synchronizing the application and driver will not be possible…probably
this was all my question. I should have put it rightly.

Thanks for the patient responses.

On 5/14/07, xxxxx@hotmail.com wrote:

> I dont want to use IRPs… I just want to store all the buffer addresses at
one go and make
> the driver write to those continuously… which inturn my app will
read.

What makes you believe that this is better that “inverted call”??? Don
already explained to you the potential issues here, but I am just curious
about your motivation - for this or that reason, newbies always want to
share a buffer, so that we have to explain the same thing again and again
and again…

What makes you belive that such approach can give you anything, apart from
extra worries and potential bugs???

Anton Bassov

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

15

> Ok… got it!! Synchronizing the application and driver will not be possible…

I am afraid you got it the wrong way…

The only thing we are saying is that it involves some additional work, and, in context of your problem, doing this extra work is just unreasonable - no one says that the task is impossible…

Anton Bassov

16

In case you haven’t quantified your performance needs yet, it is, as Don
pointed out, damn hard to come up with a scenario that really requires
this sort of implementation.

mm

>> xxxxx@acm.org 2007-05-14 06:04 >>>
How do yuou think you will synchronize the application and the driver?
How
will you handle detecting the application going away (crashing or being

terminated)? How will you handle not enough buffer space?

This is an incredibly poor design for a driver, that has been discussed

many times in this forum. Loon for subjects like “event sharing” to
see
that this is a bad idea. Unless you are doing extremely fast I/O (i.e.

over 100MB/sec) doing this will just add incredibly to your work, and
make
your driver likely to crash. As a newbie you should not be trying
this.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Exactly… thats my point… I dont want to use IRPs… I just want
to
> store all the buffer addresses at one go and make the driver write to

> those continuously… which inturn my app will read.
>

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer