Prev: Virtual driver
Next: What's different from XP and Vista System flow?
From: Doron Holan [MSFT] on 29 Aug 2008 23:43
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(a)nospam.nospam> wrote in message
news:eGpGZ4VCJHA.2480(a)TK2MSFTNGP02.phx.gbl...
>
>
> "Doron Holan [MSFT]" <doronh(a)online.microsoft.com> wrote in message
> news:#erdV4SCJHA.2060(a)TK2MSFTNGP05.phx.gbl...
>> 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(a)gmail.com> wrote in message
>> news:1cc364ba-649e-4bae-b37b-925de49852a9(a)c65g2000hsa.googlegroups.com...
>>> On Aug 28, 8:13 am, "Ben Voigt [C++ MVP]" <r...(a)nospam.nospam> 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?
>>

From: Ben Voigt [C++ MVP] on 3 Sep 2008 13:17
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(a)nospam.nospam> wrote in message
> news:eGpGZ4VCJHA.2480(a)TK2MSFTNGP02.phx.gbl...
>>
>>
>> "Doron Holan [MSFT]" <doronh(a)online.microsoft.com> wrote in message
>> news:#erdV4SCJHA.2060(a)TK2MSFTNGP05.phx.gbl...
>>> 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(a)gmail.com> wrote in message
>>> news:1cc364ba-649e-4bae-b37b-925de49852a9(a)c65g2000hsa.googlegroups.com...
>>>> On Aug 28, 8:13 am, "Ben Voigt [C++ MVP]" <r...(a)nospam.nospam>
>>>> 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?


From: Doron Holan [MSFT] on 3 Sep 2008 13:34
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(a)nospam.nospam> wrote in message
news:O7l7AheDJHA.2292(a)TK2MSFTNGP02.phx.gbl...
> 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(a)nospam.nospam> wrote in message
>> news:eGpGZ4VCJHA.2480(a)TK2MSFTNGP02.phx.gbl...
>>>
>>>
>>> "Doron Holan [MSFT]" <doronh(a)online.microsoft.com> wrote in message
>>> news:#erdV4SCJHA.2060(a)TK2MSFTNGP05.phx.gbl...
>>>> 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(a)gmail.com> wrote in message
>>>> news:1cc364ba-649e-4bae-b37b-925de49852a9(a)c65g2000hsa.googlegroups.com...
>>>>> On Aug 28, 8:13 am, "Ben Voigt [C++ MVP]" <r...(a)nospam.nospam>
>>>>> 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?
>
>

From: Ben Voigt [C++ MVP] on 3 Sep 2008 16:15
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(a)nospam.nospam> wrote in message
> news:O7l7AheDJHA.2292(a)TK2MSFTNGP02.phx.gbl...
>> 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(a)nospam.nospam> wrote in message
>>> news:eGpGZ4VCJHA.2480(a)TK2MSFTNGP02.phx.gbl...
>>>>
>>>>
>>>> "Doron Holan [MSFT]" <doronh(a)online.microsoft.com> wrote in message
>>>> news:#erdV4SCJHA.2060(a)TK2MSFTNGP05.phx.gbl...
>>>>> 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(a)gmail.com> wrote in message
>>>>> news:1cc364ba-649e-4bae-b37b-925de49852a9(a)c65g2000hsa.googlegroups.com...
>>>>>> On Aug 28, 8:13 am, "Ben Voigt [C++ MVP]" <r...(a)nospam.nospam>
>>>>>> 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?


From: Doron Holan [MSFT] on 3 Sep 2008 17:28
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

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(a)nospam.nospam> wrote in message
news:ORV1HEgDJHA.528(a)TK2MSFTNGP06.phx.gbl...
> 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(a)nospam.nospam> wrote in message
>> news:O7l7AheDJHA.2292(a)TK2MSFTNGP02.phx.gbl...
>>> 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(a)nospam.nospam> wrote in message
>>>> news:eGpGZ4VCJHA.2480(a)TK2MSFTNGP02.phx.gbl...
>>>>>
>>>>>
>>>>> "Doron Holan [MSFT]" <doronh(a)online.microsoft.com> wrote in message
>>>>> news:#erdV4SCJHA.2060(a)TK2MSFTNGP05.phx.gbl...
>>>>>> 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(a)gmail.com> wrote in message
>>>>>> news:1cc364ba-649e-4bae-b37b-925de49852a9(a)c65g2000hsa.googlegroups.com...
>>>>>>> On Aug 28, 8:13 am, "Ben Voigt [C++ MVP]" <r...(a)nospam.nospam>
>>>>>>> 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?
>
>

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Virtual driver
Next: What's different from XP and Vista System flow?