Re: USB device detection via query registry information



sermouse opens the underlying serial port just like an app does. are you seeing this with the in box serial.sys driver? or with a 3rd party driver like one for a usb->serial device?

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message news:O7l7AheDJHA.2292@xxxxxxxxxxxxxxxxxxxxxxx
Doron Holan [MSFT] wrote:
for serial mouse detection, there is a window between detection and
driver load. serenum opens the port, detects the device, closes the
port and then enumerates the child device. the child device stack
will then attempt to open the port again. in between the serenum
close and the child stack open, your app can easily open the port. if you do open the port in this window, the serial mouse driver will
fail to open the port and fail the pnp start

What I observed was:

My application had an open handle to the port.

AND

The serial mouse driver was spamming my system with pointer motion and mouse clicks.

I cannot tell you with certainty which opened the port first, I just understand that it should not be possible for both sermouse and a user-mode application to have the port open no matter which goes first. My application opened the port using the device interface path received through WM_DEVICECHANGE and SetupDi* queries. Is there any chance that the way file sharing and exclusivity is enforced might this and the DosDevices link these as separate? Although, I should think that serenum and sermouse should also use the raw interface path.


d


"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message
news:eGpGZ4VCJHA.2480@xxxxxxxxxxxxxxxxxxxxxxx


"Doron Holan [MSFT]" <doronh@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:#erdV4SCJHA.2060@xxxxxxxxxxxxxxxxxxxxxxx
i agree with chris, i have never heard of this happening

I don't remember for sure, but I think I observed this behavior
fairly frequently when the device was surprise removed and
reinserted (i.e. bus reset) all before WM_DEVICECHANGE processing
for the original insertion completed.

Of course, it could be the communication protocol with the device
itself broke down and never reached the ready state. There's a lot
of additional testing needed on the system.

I am quite sure about the mouse issue though. I was able to open a
handle to the com port and Windows also decided to detect a mouse. This shouldn't be possible, either Windows should detect the mouse
first and my CreateFile fails or else my CreateFile succeeds first
and then SERENUM can't listen for data to run its heuristic mouse
detection. There's another problem where disabling the device in the
WM_DEVICECHANGE handler reliably and reproducibly shuts down the
entire Windows Device Manager / Plug and Play system. (This was one
attempted workaround for the aforementioned false mouse detection).

This is why I say WM_DEVICECHANGE isn't a 100% reliable method for
determining when the device is ready for use.


d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.


<chris.aseltine@xxxxxxxxx> wrote in message
news:1cc364ba-649e-4bae-b37b-925de49852a9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Aug 28, 8:13 am, "Ben Voigt [C++ MVP]" <r...@xxxxxxxxxxxxx>
wrote:
Next, WM_DEVICECHANGE is quite unreliable. It is necessary to
also poll the
list of ports (of course using SetupDi* functions, not registry
access, and
test the device state) because the user-mode WM_DEVICECHANGE
handler needs
an arbitrary amount of time to complete (by definition, user-mode
processes
can be blocked by higher-priority user or kernel tasks) and some
device insertion notifications are not delivered in this case.

I've never heard of or observed this phenomenon, and your
explanation for why you think it happens is nebulous at best. Do
you have a reproducible example?



.



Relevant Pages

  • Re: USB device detection via query registry information
    ... specific parts of a driver. ... it correctly enforces exclusivity to the port ... for Windows being crash-prone? ... serenum opens the port, detects the device, ...
    (microsoft.public.development.device.drivers)
  • Re: USB device detection via query registry information
    ... WHQL is not a 100% measure of quality across an entire driver, rather it is a set of tests specifically designed to test very specific parts of a driver. ... serenum and sermouse work as expected on the in box version of serial, it correctly enforces exclusivity to the port ... serenum and sermouse are out-of-the-box XP as far as I can determine. ... serenum opens the port, detects the device, closes the ...
    (microsoft.public.development.device.drivers)
  • RE: redhat-list Digest, Vol 4, Issue 38
    ... Re: Iptables: port 22 open only for my IP ... Windows Services for Unix 3.5 ... It does absolutely nothing if you have a rampant application on your Windows box that opens a port to the outside world. ...
    (RedHat)
  • Re: USB device detection via query registry information
    ... parts of a driver. ... it correctly enforces exclusivity to the port ... serenum and sermouse are out-of-the-box XP as far as I can determine. ... serenum opens the port, detects the device, ...
    (microsoft.public.development.device.drivers)
  • Re: Legacy serial mouse for Win2000
    ... sermouse requires enumeration b/c it relies on its PDO to be the port it is ... enumerated device and open the serial port. ... > attaches to the serial.sys device stack, or a root-enumerated driver ...
    (microsoft.public.development.device.drivers)

Loading