Re: USB device detection via query registry information



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

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.


"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?


.