Event handles in WinCE
Maxim S. Shatskih
to the NDIS IM driver.
The event is created by the app and is "pushed" to the driver. After this,
the app will sometimes WaitForSingleObject on this event, and the driver will
sometimes set it or reset it to denote some moments in its life.
This works fine in Windows, just use the ObReferenceObjectByHandle routine
in the kernel part. How to do this in CE? What functions must I call?
DuplicateHandle?
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Steve Maillet (eMVP)
a named event. That way the app and driver each gets it's own handle to the
event. and there is no issue of cross process handle duplication etc...
--
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com
Maxim S. Shatskih
> a named event.
Sorry, on Windows NT, passing the handle around is a good idea, and the named
event is bad.
The reason is that the namespace structure is not guaranteed to be constant on
all Windows versions, and - for instance - it depends on whether the app is
running from the Remote Desktop or not so. Using named events for such a
purpose was deprecated by MS (at least by MS spokespersons on Windows kernel
forum).
Creating the unnamed event object in user app, passing the handle as IOCTL
parameter, ObReferenceObjectByHandle in the kernel code, and then
ObDereferenceObject when the file handle (used for IOCTL above) is closed -
this is the recommended way on NT. One of.
On Windows CE, looks like I will follow the your suggestion. Thanks!
Steve Maillet (eMVP)
quite right to me - even on XP. But named events is definitely the way to go
on the CE side.
Maxim S. Shatskih
need different names - the "\BaseNamedObjects" prefix and such. MS does not
guarantee this namespace structure to be the same in all Windows, and it is
dependent on whether the app is running from TS/Remote Desktop or not so.
On the other hand, the way with unnamed event passed from the app to the
driver has no serious drawbacks.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"Steve Maillet (eMVP)" <nos...@EntelechyConsulting.com> wrote in message
news:eId5TwRA...@TK2MSFTNGP10.phx.gbl...
Kent Lottis [MS]
on this one. Using anonymous events is, in fact, a perfectly fine way to
synchronize between application and driver. Using named events runs the risk
of namespace collision.
Just use DuplicateHandle in your driver, sort of like this:
if (! DuplicateHandle(GetCallerProcess(), hApplicationEventHandle,
GetCurrentProcess(), &hDriverEventHandle, 0, FALSE, DUPLICATE_SAME_ACCESS))
{
handle_error_condition("Unable to duplicate synchronization event
handle");
}
Of course, the driver needs to make sure to clean up the duplicate handle
when the client process shuts down, but we all know how to do that, right?
--
Kent Lottis
Dev Lead, Windows CE Multimedia
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © Microsoft Corporation. All rights
reserved.
Steve Maillet (eMVP)
one! ;-)
Namespace collision isn't a real world problem or even a problem at all if
the name is made in the form <CompanyName>\<DriverName>\<EventPurpose>
Microsoft itself uses named events throughout the system for this same kind
of purpose. (although they don't include the company name in them they do
have scoping like "PowerManager\..." etc...) While it's possible somebody
could create an event using your company name; the lawyers tend to make that
an unlikely real world scenario.
I consider this superior to the unnamed version as it is simpler to
implement and performs the same functionality. Also DuplicateHandle isn't
supported on all versions of CE currently in use so portability can be an
issue with that.
Since we are talking now about ideas of better ways to do things... I think
it's not a good idea to share an event in this manner anyway. It complicates
the application code with internal knowledge of driver implementation
details tightly coupling the driver and application unnecessarily. The
driver can have the event entirely internally and provide an IoControl (or
whatever mechanism is appropriate for the type of driver in question -
Custom OIDs for network cards etc...) The application just then calls
that.This allows the driver to use something other than an actual OS event
in a future revision without altering or re-compiling/linking the
application at all. Perhaps a semaphore or Mutex is more efficient or allows
greater flexibility in the driver implementation when some new feature is
added.[A really good driver might provide a static library that hides the
nitty gritty of making that call into a nice simple API like
WaitForDeviceEventX(hDev) or something.] For a sample of this approach look
at WaitCommEvent() it's an API Wrapper around DeviceIoctlCalls to the serial
driver that then waits on an internal event in the driver. If there is a
more efficient or better mechanism than an Event only the driver needs
updating the application is oblivious to the implementation details and
particularly the existence of the event.
Maxim S. Shatskih
> it's not a good idea to share an event in this manner anyway. It complicates
> the application code with internal knowledge of driver implementation
> details tightly coupling the driver and application unnecessarily. The
On NT, you will also need to invent the security descriptor for a named object.
Unnamed object is secure by definition :-)
Bob
windows ce? suppose some "evil" application starts
to randonmly signal or reset my events. how can i
protect that from happening?
Maxim S. Shatskih
Wi-Fi adapter. Soft reset is necessary.
The following occurs in sequence:
- the upper edge receives a power OID of going to sleep
- the lower egde receives a ProtocolPnPEvent indication of going to
sleep to D3 and promotes it up by NdisIMNotifyPnPEvent
- then the lower edge receives the media disconnect (0x4001000c) status
indication and pends it inside itself (see the source). The status indication
is not promoted up. For now, all is according to the logic of the PASSTHRU's
authors.
- just after the media disconnect indication, the device powers off.
Now the sequence of events on resume, when the power button is pressed:
- upper egde gets a power OID of wakeup to D0
- the OID routine indicates the saved media status up - for now, it is
media disconnect status
- then NDIS calls our BindAdapter (for what? is it correct to rebind on
each power state change? maybe it is possible to suppress this in some way?)
recursively to bind to our own upper egde, which is checked and rejected. From
this I conclude that TCPSTK also receives BindAdapter to our adapter at this
moment. Looks like NDIS re-calls BindAdapter for all protocols after the IM's
virtual miniport's upper edge went D0. Note: our lower edge is not re-bound.
BindAdapter is not called with the name of the real underlying adapter.
- then OID_GEN_LINK_SPEED query arrives (dunno from where, possibly
from TCPSTK's BindAdapter), and is pended by the well-known PASSTHRU's code
snippet till the lower egde will receive ProtocolPnPEvent/NetEventSetPower/D0.
- and here the OS deadlocks. The device is dead with the blank screen.
Soft reset helps, though.
- looks like NDIS has only 1 thread which both calls all BindAdapter
routines, and all ProtocolPnPEvent routines. So, the thread is waiting for
OID_GEN_LINK_SPEED to complete and cannot deliver the power-up indication to
IM's ProtocolPnPEvent, and OID_GEN_LINK_SPEED is pended till this very
indication. A deadlock.
Is it normal? Is there any success stories on power-cycling the PPC 2003
device with Wi-Fi adapter with PASSTHRU installed?
And this is only one of the multitude of issues I observe. The issues are
connected to the power management and occur when tapping the "Switch Wireless
Off" phrase in the balloon appearing from the double-arrow (networking) taskbar
icon.
The iPaq's native "Wireless tool", which has 2 huge buttons of "Enable
Bluetooth" and "Enable Wi-Fi- " also causes the issues.
The issues are that, once being switched off, the Wi-Fi adapter cannot
awaken and be up and running again. The BindAdapter path is executed fine, and
then my logfile shows the 802.11 OID queries like RSSI, and they are failed
with "media disconnected" status.
I have a strong feeling that bind/unbind must not occur on power management
events. Why NDIS does so? How to disable this behaviour?
Maxim S. Shatskih
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"Bob" <b...@somewhere.ch> wrote in message
news:%23PkdrVV...@TK2MSFTNGP09.phx.gbl...
Steve Maillet (eMVP)
way to get a valid handle to twiddle with. But remember a lot for devices.
Including Pocket PCs at this point are built with everything running in
KMODE so all processes effectively have free reign on the entire system.
(Anybody remember - "Core Wars?")
Bob
How does that work with a secure device, for
instance a smartphone? What about an application
that has OEM_CERTIFY_RUN trust? If that app
runs in kernel mode, wouldn't it be possible
to cirumvent the security to gain OEM trust? Or
isn't this true for a Smartphone?
"Steve Maillet (eMVP)" <nos...@EntelechyConsulting.com> wrote in message
news:uGaFsPWA...@tk2msftngp13.phx.gbl...
Kent Lottis [MS]
Personally, I'm becoming a great fan of Point-to-Point message queues, which
I think might provide a good compromise between simple events and a separate
abstraction layer that obscures the driver from the client code.
Maxim S. Shatskih
Oh yes :-)