Hello
I want to notify user mode application from kernel mode component. For example, something will happen in kernel, and my driver will send msg to add a string to listbox in user mode app. (Like sendmessage()).
How can/must i do this?
The approach that’s the most flexible and the easiest to get right is to have a user mode app pend an IRP, typically an IOCTL, and have the driver complete the IRP when it wants user mode to take some action. This is often referred to as the “inverted call model”, and there’s lots of information on this list and in the WDK documentation on how it works, plus sample code.
This approach also allows you to include some data with the signalling that there’s work to do.
Some subsystems provide their own communication primatives that you should prefer if they are applicable to you; for example, fltmgr provides FltSendMessage for the usage of minifilters.
There exist some general alternatives (i.e. Event objects), but they have pitfalls, (in general) few gains over pended IOCTLs, and incur many subtle issues with respect to security and reliability that the I/O manager takes care of for you with a pended IRP.
? S
-----Original Message-----
From: xxxxx@gmail.com
Sent: Saturday, January 10, 2009 09:09
To: Windows System Software Devs Interest List
Subject: [ntdev] How to send msg to user mode?
Hello
I want to notify user mode application from kernel mode component. For example, something will happen in kernel, and my driver will send msg to add a string to listbox in user mode app. (Like sendmessage()).
How can/must i do this?
—
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
It is called IoCompleteRequest. You send an IRP and the kernel responds to
it by completing it when the notification conditions arise.
This is a common question, and it has a simple answer. Key here is you have
to stop thinking in the model “my driver will send a message” and think in
terms of “my driver will notify the app”, and the problem falls apart.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, January 10, 2009 12:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to send msg to user mode?
Hello
I want to notify user mode application from kernel mode component. For
example, something will happen in kernel, and my driver will send msg to add
a string to listbox in user mode app. (Like sendmessage()).
How can/must i do this?
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
I searched “inverted call”, found a lot of answers and an article. I think it is easier than using undocumented LPC apis. So you all prefer to use it.
Thanks…
It is NOT that it is easier, it is that it is the most efficient method that
can be written to handle all the ‘edge cases’.
Edge cases:
- Application is killed by Task Manager, or abends (crashes).
- Application terminates without IoCtl being completed but still stranded
in the driver. - Driver must supply data to the application and not just a signal.
Limits:
- Some drivers in some stacks such as NDIS don’t have accessible Device
Objects. Creating one for this type of driver may cause WHQL failure. - Some instances only need a notification but no data from the driver. To
properly handle unexpected termination of the application, an inverted call
is needed so the event handle can be invalidated and not referenced which
would produce a BSOD. This is a very rare case, but I have had a need to
use it in a test harness. In that case I didn’t even use the inverted call
to handle cleanup since this was an internal tool only used by QA engineers. - Sometimes using WMI may be a better choice but that is determined by
specific stack and security requirements. WMI can be prohibited for
non-admin users for either reads or writes and by specific request.
wrote in message news:xxxxx@ntdev…
>I searched “inverted call”, found a lot of answers and an article. I think
>it is easier than using undocumented LPC apis. So you all prefer to use it.
>
> Thanks…
>
>
So you are saying that you think that using an undocumented API (which does and can change over time between releases) is preferable to something that is tried and true and works on all released OS’s the same way? Why would you want to do that ? I am really curious as to why you think LPC is better? Because it uses “messages” ?
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, January 10, 2009 11:23 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to send msg to user mode?
I searched “inverted call”, found a lot of answers and an article. I think it is easier than using undocumented LPC apis. So you all prefer to use it.
Thanks…
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
>
So you are saying that you think that using an undocumented API (which
does and can change over time between releases) is preferable to
something
that is tried and true and works on all released OS’s the same way?
Why
would you want to do that ? I am really curious as to why you think
LPC is
better? Because it uses “messages” ?
Is your parser broken tonight Doron (if not then mine is)? Maybe English
isn’t his first language but I don’t think he’s disagreeing with you.
James
My 2 cents,
Apart from inverted call, you can think of using “WMI Event Notification”,-
you can notify your driver event(s) thru WMI. Any app can get these WMI
notification, by registering to it. For more info,
http://msdn.microsoft.com/en-us/library/ms799841.aspx
Regards,
T.V.Gokul.
> I am really curious as to why you think LPC is better?
Actually, the only thing I am truly curious about is how LPC (which happens to be IPC mechanism that involves marshaling parameters) may be possibly related to KM-UM communication, in the first place - I really have no clue why the OP mentioned LPC here…
Because it uses “messages” ?
It seems to be the most plausible explanation to the whole thing - after all, the OP wants to send a message. In such case he should not limit himself only to LPC but to investigate MAPI, MSMQ, window messages and all other mechanism where the term “message” is used in mechanism’s description - relevance of a mechanism in question in a given context seems to be the last thing the OP is concerned about…
Anton Bassov
why would having to implement kernel and usermode WMi code, offhand
about 10x the size of a simple IOCTL interface, be preferable?
I suppose that under stress WMI does have the advantage of
unreliability, so there is that.
On 1/11/09, Gokul TV wrote:
> My 2 cents,
>
> Apart from inverted call, you can think of using “WMI Event Notification”,-
> you can notify your driver event(s) thru WMI. Any app can get these WMI
> notification, by registering to it. For more info,
> http://msdn.microsoft.com/en-us/library/ms799841.aspx
>
> Regards,
> T.V.Gokul.
>
> —
> 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
>>why would having to implement kernel and usermode WMi code, offhand
>about 10x the size of a simple IOCTL interface, be preferable?
I agree, the WMI implementation is bit complex when comapred to the IOCTL
impementation; but WMI has its inherit merits like easy remote management
and also tomo if you want to report one other different event or to
instrument the driver from an app, you can easily acheive this by extending
your existing MOF.
>I suppose that under stress WMI does have the advantage of
>unreliability, so there is that.
I’m not aware of this. Can you please eloborate on this? Even if you provide
any pointers/external links, that would be great…
Regards,
T.V.Gokul.
Wmi allocates a bunch of memory in both the sending and receiving sides of the request. An ioctl has an allocation on the sending side (the irp and either the mdl or double buffer) only
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
From: Gokul TV
Sent: Sunday, January 11, 2009 7:29 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] How to send msg to user mode?
>>why would having to implement kernel and usermode WMi code, offhand
>>about 10x the size of a simple IOCTL interface, be preferable?
I agree, the WMI implementation is bit complex when comapred to the IOCTL impementation; but WMI has its inherit merits like easy remote management and also tomo if you want to report one other different event or to instrument the driver from an app, you can easily acheive this by extending your existing MOF.
>>I suppose that under stress WMI does have the advantage of
>>unreliability, so there is that.
I’m not aware of this. Can you please eloborate on this? Even if you provide any pointers/external links, that would be great…
Regards,
T.V.Gokul.
— 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
I can only give my personal experience. I worked on a platform management
monitoring interface that made extensive use of WMI events and queries in
kernel mode components to provide the management service applications real
time state information. We eventually had to scrap that design because when
we put our systems under IO stress and then started pulling components out
or otherwise inducing them to fail (which was the point of all of our
monitoring - to detect these sorts of system state changes) the volume of
WMI events going up from kernel mode to user mode overwhelmed internal
assumptions within WMI about what ‘a lot’ might be. We substituted our own
event mechanism instead.
Of course this platform was and is a bit unusual in that it supports
component failures under stress to begin with, so probably WMI would work
fine under more ‘normal’ conditions.
Mark Roddy
On Sun, Jan 11, 2009 at 10:27 AM, Gokul TV wrote:
> >>why would having to implement kernel and usermode WMi code, offhand
> >>about 10x the size of a simple IOCTL interface, be preferable?
> I agree, the WMI implementation is bit complex when comapred to the IOCTL
> impementation; but WMI has its inherit merits like easy remote management
> and also tomo if you want to report one other different event or to
> instrument the driver from an app, you can easily acheive this by extending
> your existing MOF.
>
> >>I suppose that under stress WMI does have the advantage of
> >>unreliability, so there is that.
>
> I’m not aware of this. Can you please eloborate on this? Even if you
> provide any pointers/external links, that would be great…
>
> Regards,
> T.V.Gokul.
> — 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
>
That sounds like an argument in favor of a shared memory strategy, where no
allocations need to happen.
It seems like ANY user mode code is at the mercey of low memory though,
because it’s pagable.
Jan
Wmi allocates a bunch of memory in both the sending and receiving sides of
the request. An ioctl has an allocation on the sending side (the irp and
either the mdl or double buffer) only
> why would having to implement kernel and usermode WMi code,
offhand about 10x the size of a simple IOCTL interface, be preferable?
I suppose that under stress WMI does have the advantage of
unreliability, so there is that.
I don’t know, the user mode side of receiving WMI events can be REALLY easy.
Easier that writing a service, and WMI handles all the event queuing. You
can write a WMI event trigger in a dozen line .mof file which can feed the
events to another dozen line chunk of VBScript. This method is more
appropriate for lower bandwidth interfaces. I believe you can also install a
WMI event forwarder, and make the events fired from the driver show up
across a network on another machine, or make the events cause some action in
a remote system management console.
You can also communicate back to the driver via WMI set/get/methods, even
from a remote machine.
You also can have multiple driver instances generating events to a single
user mode handler. The inverted call interface get’s more complex when you
have multiple device instances, which dynamically may come and go. You also
can have multiple user mode clients register to receive the events with no
changes to the driver. This would be handy if say you provide a base set of
event handing as part of your product, but by documenting the WMI event
interface, customers can write user mode code that does custom stuff,
sysadmin people could write VBScript event handlers, triggered by your
driver. As an example, you could fire a WMI event when something bad is
detected by your device, and the customer written user mode event script
could send email to an admin (this is probably less than 50 lines of
VBScript event handler code).
On the kernel mode side, if you support WMI already (which production
drivers should anyway) it’s pretty simple to add some event definitions to a
.mof file and then fire those events.
As for robustness, the WMI process seems to try pretty hard to do it’s job.
Sending a WMI event is certainly massively more complex (and therefore at
risk for failure) than waking up a worker thread or completing an IOCTL.
I probably would not try and implement a user mode virtual scsi device using
WMI events, but if I had low bandwidth information to pass back and forth
between a driver and user mode, it’s one of the available options. A WMI
event hander is especially useful if it’s fuzzily defined what you want to
do in user mode in response to the kernel triggered event, or you want
customers to be able to extent the user mode actions.
Jan
As long as the storage stack can make guaranteed forward progress, though, just because user mode code is pagable shouldn?t mean it will fail (timing aside) ? right?
- S
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Sunday, January 11, 2009 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to send msg to user mode?
That sounds like an argument in favor of a shared memory strategy, where no allocations need to happen.
It seems like ANY user mode code is at the mercey of low memory though, because it’s pagable.
Jan
Wmi allocates a bunch of memory in both the sending and receiving sides of the request. An ioctl has an allocation on the sending side (the irp and either the mdl or double buffer) only
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
> That sounds like an argument in favor of a shared memory strategy, where no allocations
need to happen.
…but the performance gains that may result from eliminating a need to do allocations are more than likely to be washed away by the overhead implied by the need to synchronize an access to the buffer (please note that memory allocations don’t require context switch)…
When it comes to the long-term memory consumption it does not really matter which mechanism you use - if you use shared buffer you will have to lock MDL that describes it in RAM, and if you use IOCTLs, every pending IRP will consume the space in the system IO buffer, which belongs to non- pageable memory (I assume METHOD_BUFFERED - if you use METHOD_DIRECT, again, the system will lock MDL describing IRP’s IO buffer in RAM).
Although it is hard to say anything without knowing all details of a given app, I would say that in vast majority of cases inverted call will be more reasonable option, compared to shared buffer…
Anton Bassov
You certainly could NOT do something like the system boot/paging disk
implemented as a virtual storage driver refelcting requests to a user mode
service. The system would deadlock as soon as the virtual disk service
needed to use itself to fault in a non-resident page. This pretty much rules
out user mode file systems/file system filters implemented for the
boot/paging disk too. Since the system boot disk might be iSCSI, this also
means things like network filters implemented as a driver+user mode service
to do the packet classification would be problematic.
Jan
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Sunday, January 11, 2009 2:32 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to send msg to user mode?
As long as the storage stack can make guaranteed forward progress, though,
just because user mode code is pagable shouldn’t mean it will fail (timing
aside) - right?
- S
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Sunday, January 11, 2009 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to send msg to user mode?
That sounds like an argument in favor of a shared memory strategy, where no
allocations need to happen.
It seems like ANY user mode code is at the mercey of low memory though,
because it’s pagable.
Jan
Wmi allocates a bunch of memory in both the sending and receiving sides of
the request. An ioctl has an allocation on the sending side (the irp and
either the mdl or double buffer) only
Certainly agree that anything in the ?critical path? for the set of all code paths required to in-page a particular page shouldn?t create a circular dependency like that.
The OP didn?t specify that they were in a paging path such that they?d create a circular dependency inside that particular paging path, though (or perhaps I missed it?). Assuming that they aren?t in such a situation, it should be possible to write user mode code that doesn?t have any non-recoverable failures (assuming appropriate care is taken to handle well-defined possibly failing sequence points actually failing, i.e. IOCTL request failing due to inability to allocate resources).
- S
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, January 12, 2009 2:52 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to send msg to user mode?
You certainly could NOT do something like the system boot/paging disk implemented as a virtual storage driver refelcting requests to a user mode service. The system would deadlock as soon as the virtual disk service needed to use itself to fault in a non-resident page. This pretty much rules out user mode file systems/file system filters implemented for the boot/paging disk too. Since the system boot disk might be iSCSI, this also means things like network filters implemented as a driver+user mode service to do the packet classification would be problematic.
Jan
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Sunday, January 11, 2009 2:32 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to send msg to user mode?
As long as the storage stack can make guaranteed forward progress, though, just because user mode code is pagable shouldn?t mean it will fail (timing aside) ? right?
- S
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Sunday, January 11, 2009 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to send msg to user mode?
That sounds like an argument in favor of a shared memory strategy, where no allocations need to happen.
It seems like ANY user mode code is at the mercey of low memory though, because it’s pagable.
Jan
Wmi allocates a bunch of memory in both the sending and receiving sides of the request. An ioctl has an allocation on the sending side (the irp and either the mdl or double buffer) only
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
Yes sure the user mode side, if you implement it using one of the .netish
languages, is easy. The kernel side is just a whole pile of boilerplate
nonsense that ends up bloating your driver. If your driver is already
supporting WMI, not such a big deal, if it isn’t, then choosing to use this
approach seems unwise to me.
Mark Roddy
On Sun, Jan 11, 2009 at 5:21 PM, Jan Bottorff wrote:
> > why would having to implement kernel and usermode WMi code,
> > offhand about 10x the size of a simple IOCTL interface, be preferable?
> >
> > I suppose that under stress WMI does have the advantage of
> > unreliability, so there is that.
>
> I don’t know, the user mode side of receiving WMI events can be REALLY
> easy.
> Easier that writing a service, and WMI handles all the event queuing. You
> can write a WMI event trigger in a dozen line .mof file which can feed the
> events to another dozen line chunk of VBScript. This method is more
> appropriate for lower bandwidth interfaces. I believe you can also install
> a
> WMI event forwarder, and make the events fired from the driver show up
> across a network on another machine, or make the events cause some action
> in
> a remote system management console.
>
> You can also communicate back to the driver via WMI set/get/methods, even
> from a remote machine.
>
> You also can have multiple driver instances generating events to a single
> user mode handler. The inverted call interface get’s more complex when you
> have multiple device instances, which dynamically may come and go. You also
> can have multiple user mode clients register to receive the events with no
> changes to the driver. This would be handy if say you provide a base set of
> event handing as part of your product, but by documenting the WMI event
> interface, customers can write user mode code that does custom stuff,
> sysadmin people could write VBScript event handlers, triggered by your
> driver. As an example, you could fire a WMI event when something bad is
> detected by your device, and the customer written user mode event script
> could send email to an admin (this is probably less than 50 lines of
> VBScript event handler code).
>
> On the kernel mode side, if you support WMI already (which production
> drivers should anyway) it’s pretty simple to add some event definitions to
> a
> .mof file and then fire those events.
>
> As for robustness, the WMI process seems to try pretty hard to do it’s job.
> Sending a WMI event is certainly massively more complex (and therefore at
> risk for failure) than waking up a worker thread or completing an IOCTL.
>
> I probably would not try and implement a user mode virtual scsi device
> using
> WMI events, but if I had low bandwidth information to pass back and forth
> between a driver and user mode, it’s one of the available options. A WMI
> event hander is especially useful if it’s fuzzily defined what you want to
> do in user mode in response to the kernel triggered event, or you want
> customers to be able to extent the user mode actions.
>
> Jan
>
>
>
>
> —
> 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
>