Prev: Virtual driver
Next: What's different from XP and Vista System flow?
From: David Miller on 28 Aug 2008 17:24
Look at the BSF_NOHANG and BSF_FORCEIFHUNG flags in BroadcastSystemMessage().

http://msdn.microsoft.com/en-us/library/ms644932(VS.85).aspx


"Doron Holan [MSFT]" wrote:

> i agree with chris, i have never heard of this happening
>
> 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: David Miller on 28 Aug 2008 17:34
Oops. I forgot the most important flag of all:

BSF_NOTIMEOUTIFNOTHUNG

“Waits for a response to the message, as long as the recipient is not being
unresponsive. Does not time out.”


"Doron Holan [MSFT]" wrote:

> i agree with chris, i have never heard of this happening
>
> 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: David Miller on 28 Aug 2008 18:30
"Ben Voigt [C++ MVP]" wrote:

> Perhaps someone can explain why WM_DEVICECHANGE messages are sent rather
> than posted?

PostMessage() can't marshall the DEV_BROADCAST_HDR structure in the lParam.

I bet BroadcastSystemMessage() is calling SendMessageTimeout() or doing
something similar. FYI SendMessageTimeout() gives each window five seconds
to respond.

“This function considers a thread is not responding if it has not called
GetMessage or a similar function within five seconds.”

http://msdn.microsoft.com/en-us/library/ms644952(VS.85).aspx


From: Ben Voigt [C++ MVP] on 28 Aug 2008 18:33


"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 28 Aug 2008 18:38


"David Miller" <DavidMiller(a)discussions.microsoft.com> wrote in message
news:BC9F47D5-B220-4732-B20D-AB39FE416266(a)microsoft.com...
> Oops. I forgot the most important flag of all:
>
> BSF_NOTIMEOUTIFNOTHUNG
>
> “Waits for a response to the message, as long as the recipient is not
> being
> unresponsive. Does not time out.”
>

The question is: Which of the flags is used to send WM_DEVICECHANGE? And
does it vary at all based on the driver?

Also, how is "not being unresponsive" determined? If a thread is trying to
pump messages but doesn't get scheduled due to other activities, is that
unresponsive? How about if a 30ms (cpu time, not wall clock time) handler
with no message pumping gets pre-empted by other threads?

There are generally no bounds on the time needed for a user thread to
complete a task on a system shared with other arbitrary threads.

>
> "Doron Holan [MSFT]" wrote:
>
>> i agree with chris, i have never heard of this happening
>>
>> 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?