Re: USB device detection via query registry information

Doron Holan [MSFT] wrote:
a wall of shame is not practical. by getting signed, the vendor does
get a clear window into their OCA/bluescreen data that we collect. it is
up to the vendor to look the collected data.

Ok, but does the level to which they utilize that data and release fixes
influence approval of the next WHQL submission? That may be too hard to
judge, but at least making them certify that they have analyzed the
bluescreen data associated to their existing products might shock some
people into doing so.

Fixing bugs needs to be stated as mandatory and have the developer agree to
do it, regardless of the actual level of enforcement. Similarly vendors
need to be given a hard time if they fail to provide a driver compatible
with a new Windows version for products released in the last 3 years or
offered for sale in the last 12 months.


d


"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message
news:O51M9N2DJHA.3396@xxxxxxxxxxxxxxxxxxxxxxx
Doron Holan [MSFT] wrote:
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. why is msft reponsible for the crud
that FTDI wrote? serenum and sermouse work as expected on the in
box version of serial, it correctly enforces exclusivity to the port

WHQL is realistically not going to be able to catch all bugs before
shipment, so maybe the answer is for WHQL signing to require a
commitment from the driver developer to participate in the BSOD
crash dump program and issue timely bug fixes (this is usually what
is meant by having a "quality" process in sw development, right?). A
public "Wall of BSOD Shame" listing drivers with known bugs and no
fix might also be worth considering. Yes these things would not
come free, but is it important to Microsoft to shed the reputation
for Windows being crash-prone?

d


"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message
news:ORV1HEgDJHA.528@xxxxxxxxxxxxxxxxxxxxxxx
Doron Holan [MSFT] wrote:
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?

It's USB/serial converter, from FTDI (doesn't use communication
device class). Their driver is WHQL. I wouldn't doubt that their
driver is causing the problem since one version ago simply opening
a device on a multicore system was BSOD within 10 seconds. Which
doesn't totally absolve MS of responsibility. What's the good of
WHQL if even buggy drivers can be approved?

serenum and sermouse are out-of-the-box XP as far as I can
determine. I should be able to load the problem configuration in a
kernel
debugger and have debug output from my userland application showing
the result of the device interface open. If someone could advise
me on how to enable tracing of serenum/sermouse or where to set a
breakpoint, I could determine the order of events definitively.



"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: 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: xp pro sharing printer
    ... How to troubleshoot network printing problems in Windows XP ... SMB-connected print server ... Incompatible print driver ... and then redirect the port to the network server. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: USB device detection via query registry information
    ... Similarly vendors need to be given a hard time if they fail to provide a driver compatible with a new Windows version for products released in the last 3 years or offered for sale in the last 12 months. ... it correctly enforces exclusivity to the port ... serenum and sermouse are out-of-the-box XP as far as I can ... serenum opens the port, detects the device, ...
    (microsoft.public.development.device.drivers)
  • Re: USB device detection via query registry information
    ... it correctly enforces exclusivity to the port ... WHQL is realistically not going to be able to catch all bugs before shipment, so maybe the answer is for WHQL signing to require a commitment from the driver developer to participate in the BSOD crash dump program and issue timely bug fixes. ... Yes these things would not come free, but is it important to Microsoft to shed the reputation for Windows being crash-prone? ... serenum opens the port, detects the device, ...
    (microsoft.public.development.device.drivers)
  • Slow response when opening files
    ... opens almost instantly. ... my guess is there must be a problem with a driver. ... >Hit Apply and OK and re-start as Windows will suggest. ... >>slow response times. ...
    (microsoft.public.windowsxp.general)