Hi All,
Can somebody help me out in understanding different methods to communicate with the device driver in Windows user mode programs…
As of now i know only one method , Thats accessing the device as file based system…
Thats through Createfile method and then use the methods like read /write /DeviceIoControl
Please let me know about it …
Thanks ,
Jagadish
Define ‘device driver’. Is it a real device driver with hardware it
controls? Is it a root enumerated software device driver or a legacy
software device driver that has no devices attached? Is it a driver that
participates in a stack such as TCPIP where the device driver is not
controlling hardware, but participates in a stack where there are rules
regarding how it interfaces with the OS?
For a pure software device driver loaded as a kernel mode helper for your
application, then the only interface required is the read/write and IoCtl
methods. Usually the read/write interface is not used, but only IoCtls.
They can be tailored for the specific direction and quantity of data being
transferred. Whether the device driver creates a device object with a fixed
name and symbolic link or uses an interface GUID is the only other design
question that needs to be answered before writing the driver and the
application code that calls it. Applying security as to device exclusivity
and attributes can be changed rather easily later. If a security product,
keeping permitted invokers restricted to services running under the system
account is a good idea. A user mode service can be used for this and the
other applications can have the service provide an interface to the driver
for them.
wrote in message news:xxxxx@ntdev…
> Hi All,
>
>
> Can somebody help me out in understanding different methods to communicate
> with the device driver in Windows user mode programs…
>
> As of now i know only one method , Thats accessing the device as file
> based system…
>
>
> Thats through Createfile method and then use the methods like read /write
> /DeviceIoControl
>
> Please let me know about it …
>
>
> Thanks ,
> Jagadish
>
>
>
>
>
Hi David,
Ya currently i am looking for the ways to interact to a driver which is not a hardware bound driver , its just a monitoring driver …which doesn’t create a device object at all …So how can application or services interact with this driver …without treating it as a fileio device.
Jagadish
You can’t communicate at all without a device object other than signalling
an event through a shared event. Even then, all you could do is signal the
event, data transfers would still require a device object. Your monitor
driver can of course create a device object. Is there some reason you are
reluctant to do this?
On Feb 11, 2008 3:38 AM, wrote:
> Hi David,
>
> Ya currently i am looking for the ways to interact to a driver which is
> not a hardware bound driver , its just a monitoring driver …which doesn’t
> create a device object at all …So how can application or services interact
> with this driver …without treating it as a fileio device.
>
>
> Jagadish
>
> —
> 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
>
–
Mark Roddy
Another way to communicate with driver is WMI.
But you can not relay on it if you need intensive realtime communication
What you have not explained is why you do not want a control device object?
Sorry, but you are looking to step way outside the Windows model for and
have not given a reason. Even the WMI mentioned in a later post needs to go
through a device object. What problem do you really think is going to get
better by not using the standard windows model?
–
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…
> Hi David,
>
> Ya currently i am looking for the ways to interact to a driver which is
> not a hardware bound driver , its just a monitoring driver …which
> doesn’t create a device object at all …So how can application or
> services interact with this driver …without treating it as a fileio
> device.
>
>
> Jagadish
>
You still need a device object to receive wmi requests. The OP seems to have
developed an allergy to device objects.
On Feb 11, 2008 9:11 AM, wrote:
> Another way to communicate with driver is WMI.
> But you can not relay on it if you need intensive realtime communication
>
> —
> 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
>
–
Mark Roddy
> You still need a device object to receive wmi requests. The OP seems to have developed an allergy to device objects.
Not really (I’m about device object).
For WMI is enough to have the registered class name.
But it seems WMI has a limited queue buffer length and some messages (events) may be lost
Check again, these still have to go through an IRP through a DEVICE_OBJECT.
–
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…
>> You still need a device object to receive wmi requests. The OP seems to
>> have developed an allergy to device objects.
>
> Not really (I’m about device object).
> For WMI is enough to have the registered class name.
> But it seems WMI has a limited queue buffer length and some messages
> (events) may be lost
>
In my case the events work via
IWbemServices::ExecNotificationQueryAsync( _bstr_t(“WQL”),
_bstr_t( “SELECT * FROM WMI_ClassName” ),
WBEM_FLAG_SEND_STATUS,
NULL,
pStubSink );
But I agree - one CreateFile() much easier than bunch of CoCreateInstance() and QueryInterface()
> Not really (I’m about device object).
For WMI is enough to have the registered class name.
Kernel-mode WMI provisioning requires a device object as a target for
IRP_MJ_SYSTEM_CONTROL
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
User-mode WMI - yes (though this piece of code is more complex then
DeviceIoControl).
Kernel-mode WMI providers must be registered in kernel’s WMI, and this
requires MJ_SYSTEM_CONTROL IRPs and thus the device object.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> In my case the events work via
> IWbemServices::ExecNotificationQueryAsync( _bstr_t(“WQL”),
> _bstr_t( “SELECT * FROM
WMI_ClassName” ),
> WBEM_FLAG_SEND_STATUS,
> NULL,
> pStubSink );
>
Usually, though proper C++ usage (_com_ptr_t, #import etc) makes the COM
client code some “VBScript-style” and very easy.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, February 11, 2008 6:08 PM
Subject: RE:[ntdev] different method to access Drivers from user mode process
> But I agree - one CreateFile() much easier than bunch of CoCreateInstance()
and QueryInterface()
>
> —
> 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
Some misunderstanding, I was speaking about user side
> Check again, these still have to go through an IRP through a DEVICE_OBJECT.
Not necessarily - it depends on the target architecture. For example, if you access NDIS miniport driver via WMI you don’t have to create a standalone control device object, because NDIS will take care of everything so that your requests will go directly to your driver. I do understand what you mean - indeed, it is impossible to bypass a standard IRP-based Windows model if you want to make an app and driver communicate with one another. However, in some cases a control object may be created by the component that stands in between the OS and your driver (NDIS miniport is a typical example), so that if the system communicates with your driver by some means other than IRPs sometimes you can get away without creating your own control device object…
Anton Bassov
Never said a standalone device object, but you still need one to associate
this. Note: this is way off the OP’s original question, and the OP sitll
has not answered why they have an aversion to DEVICE_OBJECTS.
–
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…
>> Check again, these still have to go through an IRP through a
>> DEVICE_OBJECT.
>
> Not necessarily - it depends on the target architecture. For example, if
> you access NDIS miniport driver via WMI you don’t have to create a
> standalone control device object, because NDIS will take care of
> everything so that your requests will go directly to your driver. I do
> understand what you mean - indeed, it is impossible to bypass a standard
> IRP-based Windows model if you want to make an app and driver communicate
> with one another. However, in some cases a control object may be created
> by the component that stands in between the OS and your driver (NDIS
> miniport is a typical example), so that if the system communicates with
> your driver by some means other than IRPs sometimes you can get away
> without creating your own control device object…
>
> Anton Bassov
>
> Never said a standalone device object,
I know - this is NDIS-specific feature…
but you still need one to associate this.
This is what I thought as well. However, as Thomas explained to me, I was totally wrong - NDIS handles everything via its own device object…
Note: this is way off the OP’s original question,
Agreed…
Anton Bassov
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-314357-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, February 11, 2008 12:39 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] different method to access Drivers from user mode
process> Check again, these still have to go through an IRP through a
DEVICE_OBJECT.Not necessarily - it depends on the target architecture. For example,
if you access NDIS miniport driver via WMI you don’t have to create a
standalone control device object, because NDIS will take care of
everything so that your requests will go directly to your driver. I do
understand what you mean - indeed, it is impossible to bypass a
standard IRP-based Windows model if you want to make an app and driver
communicate with one another. However, in some cases a control object
may be created by the component that stands in between the OS and your
driver (NDIS miniport is a typical example), so that if the system
communicates with your driver by some means other than IRPs sometimes
you can get away without creating your own control device object…Anton Bassov
For NDIS miniports the NDIS Library creates the required device object for the miniport and handles the WMI/NDIS Request translation.
You don’t create the device object explicitly, but it is done for you. Still exists, however…
Thomas F. Divine
The OP, as has now become typical in these threads, has long since bowed out
of the discussion. The talmudic scholars of ntdev are now arguing over
minutea as we have nothing better to do.
On Feb 11, 2008 12:40 PM, Don Burn wrote:
> Never said a standalone device object, but you still need one to associate
> this. Note: this is way off the OP’s original question, and the OP sitll
> has not answered why they have an aversion to DEVICE_OBJECTS.
>
>
> –
> 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…
> >> Check again, these still have to go through an IRP through a
> >> DEVICE_OBJECT.
> >
> > Not necessarily - it depends on the target architecture. For example, if
> > you access NDIS miniport driver via WMI you don’t have to create a
> > standalone control device object, because NDIS will take care of
> > everything so that your requests will go directly to your driver. I do
> > understand what you mean - indeed, it is impossible to bypass a standard
> > IRP-based Windows model if you want to make an app and driver
> communicate
> > with one another. However, in some cases a control object may be created
> > by the component that stands in between the OS and your driver (NDIS
> > miniport is a typical example), so that if the system communicates with
> > your driver by some means other than IRPs sometimes you can get away
> > without creating your own control device object…
> >
> > Anton Bassov
> >
>
>
>
> —
> 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
>
–
Mark Roddy