User space - kernel communication

OSR_Community_User · November 20, 2009, 11:28am

Hi all,

I guess this might be rather an straightforward issue for many people in this list but since I am a newbie I need your guidance

I would like to pass a few (variable) values from user space to a callout filter driver I have implemented. I know that this can be done using IOCTL but I tried to search online and I could not find any thing really useful (in the meaning that it is also explanotory). I took a look at the msn monitor example that comes with the latest WinDDK but no luck.

I guess what I want to do is rather simple but some pointers or some layout (even at the web, since searching for it did not provide any useful results) would help me get started.

Thanks

OSR_Community_User · November 20, 2009, 11:33am

I forgot to mention that I run windows 7

Thanks

anton_bassov · November 20, 2009, 11:53am

> I know that this can be done using IOCTL but I tried to search online and I could not find any

thing really useful (in the meaning that it is also explanotory).

Actually, I don’t really know what, where and how you were searching, but , IIRC this particular site has an entire article dedicated to the topic, and this article gives really good explanation of inverted call…

Anton Bassov

OSR_Community_User · November 21, 2009, 5:29pm

Since people in the future might happen to have the same question I finally found an interesting link with details: http://www.codeproject.com/KB/system/driverdev2.aspx

However I would like to ask one question to people who know better than me I have implemented an IOCTL using the METHOD_IN_DIRECT and then I tried to create a user space application in order to send the data I wanted from the userspace at my driver (for demonstration purposes the name of the service let’s assume it is x – just to remind that my driver is a filter (callout) driver implemented on win 7 at the ALE_CONNECT_REDIRECT layer). The application uses CreateFile in order to get a handle at the driver and then uses DeviceIoControl. However DeviceIoControl is always returning 0. This means that the handle was not correctly obtained. At CreateFile method I have tried various ways to name the device/driver I want to open (for example “\.\x”). Also what about the dwShareMode parameter of CreateFile? I currently have set it to GENERIC_WRITE.

Thanks a lot

Don_Burn_1 · November 21, 2009, 6:45pm

Actually that is a poor version of the IOCTL driver in the WDK. As Anton
pointed out this site has good articles on IOCTL’s as does Microsofts site
for driver writers http://www.microsoft.com/whdc/default.mspx.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Since people in the future might happen to have the same question I
> finally found an interesting link with details:
> http://www.codeproject.com/KB/system/driverdev2.aspx
>
> However I would like to ask one question to people who know better than me
> I have implemented an IOCTL using the METHOD_IN_DIRECT and then I tried
> to create a user space application in order to send the data I wanted from
> the userspace at my driver (for demonstration purposes the name of the
> service let’s assume it is x – just to remind that my driver is a filter
> (callout) driver implemented on win 7 at the ALE_CONNECT_REDIRECT layer).
> The application uses CreateFile in order to get a handle at the driver and
> then uses DeviceIoControl. However DeviceIoControl is always returning 0.
> This means that the handle was not correctly obtained. At CreateFile
> method I have tried various ways to name the device/driver I want to open
> (for example “\.\x”). Also what about the dwShareMode parameter of
> CreateFile? I currently have set it to GENERIC_WRITE.
>
> Thanks a lot
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4627 (20091121)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4627 (20091121)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Tim_Roberts · November 23, 2009, 1:48pm

xxxxx@yahoo.com wrote:

However DeviceIoControl is always returning 0. This means that the handle was not correctly obtained.

No, it certainly does not. It means that the DeviceIoControl call
failed. The only way to know WHY it failed is to call GetLastError().

At CreateFile method I have tried various ways to name the device/driver I want to open (for example “\.\x”). Also what about the dwShareMode parameter of CreateFile? I currently have set it to GENERIC_WRITE.

Microsoft goes to all the trouble to create explicit documentation for
their APIs. It’s a shame that it doesn’t get used. GENERIC_WRITE is
used for dwDesiredAccess. It is NOT a legal value for dwShareMode.
dwShareMode uses a combination of the flags FILE_SHARE_READ,
FILE_SHARE_WRITE, and FILE_SHARE_DELETE.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Peter_Viscarola_OSR · November 23, 2009, 1:54pm

Wow… in reference to the Code Project article:

http://www.codeproject.com/KB/system/driverdev2.aspx

Like just about every article on kernel-mode programming on Code Project, this is a particularly TERRIBLE example. It shows a basic lack of understanding by the author. I found the following particularly scary:

Yikes!!

Word to the wise: Don’t believe everything you read online. CONSIDER THE SOURCE.

Peter
OSR

Prokash_Sinha-1 · November 23, 2009, 2:27pm

And the author is a semi-regular here ( May god discount my opinion !).

Once I had to follow this site to get a project that will export
makefile the way ( vs 6 and earlier was doing by IDE ), but was not in
vs 7 ( err 8). It was to give the build/release guy. Downloaded, tried
and found … Had to waste a day or two, because I did not know that
the workspace could be invoked directly from build’s makefile.

So yes, that is not a site that one should follow without thorough
investigation.

-pro

xxxxx@osr.com wrote:

Wow… in reference to the Code Project article:

http://www.codeproject.com/KB/system/driverdev2.aspx

Like just about every article on kernel-mode programming on Code Project, this is a particularly TERRIBLE example. It shows a basic lack of understanding by the author. I found the following particularly scary:

The IoCompleteRequest is always called by the driver after it completes the IRP. The reason we weren’t doing this in the previous example is that the I/O Manager being a nice guy will in most cases complete this for us. However, it is proper for the driver to complete the IRP where necessary.

Yikes!!

Word to the wise: Don’t believe everything you read online. CONSIDER THE SOURCE.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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