Prev: Virtual driver
Next: What's different from XP and Vista System flow?
From: kelly on 27 Aug 2008 07:42
Besides using the WM_DEVICECHANGE to detect a USB device insert/remove,
I tried to use scan registry information ""HARDWARE\\DEVICEMAP\\SERIALCOMM"
to check, and using CreateFile() to open USB com port right after I find a
new-coming device.
So far, the method works fine in single-core PC while in dual-core PC, I
found that if I invoke CreateFile() right after I find the device from
registry, the operation will return error code 2 (implying that "The system
cannot find the file specified.").
If I delay to invoke CreateFile() by sleep(1), for example, the error will
not occur again.
Thus, I am wondering how the initialization process of underlying driver
actually work.
Is registry update operation finished before the the device driver is ready?
Thanks!
From: Doron Holan [MSFT] on 27 Aug 2008 13:50
you are tying 2 different concept together and you are getting lucky that it
works at all. the driver writes to the SERIALCOMM key as it is starting up.
if you find the value in the middle of this start up and try to use it, yes
it will fail on CreateFile. The documented and *correct* way is to use
WM_DEVICECHANGE and register for device interface arrivals for the device(s)
you care about opening.

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.


"kelly" <kelly(a)discussions.microsoft.com> wrote in message
news:6E0EC370-4823-4BAA-AD4D-8D4A70A88274(a)microsoft.com...
> Besides using the WM_DEVICECHANGE to detect a USB device insert/remove,
> I tried to use scan registry information
> ""HARDWARE\\DEVICEMAP\\SERIALCOMM"
> to check, and using CreateFile() to open USB com port right after I find a
> new-coming device.
> So far, the method works fine in single-core PC while in dual-core PC, I
> found that if I invoke CreateFile() right after I find the device from
> registry, the operation will return error code 2 (implying that "The
> system
> cannot find the file specified.").
> If I delay to invoke CreateFile() by sleep(1), for example, the error will
> not occur again.
> Thus, I am wondering how the initialization process of underlying driver
> actually work.
> Is registry update operation finished before the the device driver is
> ready?
> Thanks!

From: Ben Voigt [C++ MVP] on 28 Aug 2008 09:13


"Doron Holan [MSFT]" <doronh(a)online.microsoft.com> wrote in message
news:u6pHn1GCJHA.1892(a)TK2MSFTNGP04.phx.gbl...
> you are tying 2 different concept together and you are getting lucky that
> it works at all. the driver writes to the SERIALCOMM key as it is
> starting up. if you find the value in the middle of this start up and try
> to use it, yes it will fail on CreateFile. The documented and *correct*
> way is to use WM_DEVICECHANGE and register for device interface arrivals
> for the device(s) you care about opening.

I am not the OP, but I wanted to weigh in on this discussion of detecting
new USB serial port (virtual com port).

Serial ports seem to be a special case. While I've never gotten "file not
found", I have been able to exclusively open the device interface path only
to find that the SERENUM filter trashed my settings and installed a mouse
driver (heuristic device identification failed -- the device is not a
mouse).

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.

Perhaps someone can explain why WM_DEVICECHANGE messages are sent rather
than posted? The only purpose for sending I can think of would be to make
configuration changes before the device becomes visible to other
applications, but WM_DEVICECHANGE isn't usable for this purpose anyway
because AFAICT the order apps receive WM_DEVICECHANGE isn't controlled, as
well as re-entrancy problems with setting device configuration from
WM_DEVICECHANGE handler.

>
> 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.
>
>
> "kelly" <kelly(a)discussions.microsoft.com> wrote in message
> news:6E0EC370-4823-4BAA-AD4D-8D4A70A88274(a)microsoft.com...
>> Besides using the WM_DEVICECHANGE to detect a USB device insert/remove,
>> I tried to use scan registry information
>> ""HARDWARE\\DEVICEMAP\\SERIALCOMM"
>> to check, and using CreateFile() to open USB com port right after I find
>> a
>> new-coming device.
>> So far, the method works fine in single-core PC while in dual-core PC, I
>> found that if I invoke CreateFile() right after I find the device from
>> registry, the operation will return error code 2 (implying that "The
>> system
>> cannot find the file specified.").
>> If I delay to invoke CreateFile() by sleep(1), for example, the error
>> will
>> not occur again.
>> Thus, I am wondering how the initialization process of underlying driver
>> actually work.
>> Is registry update operation finished before the the device driver is
>> ready?
>> Thanks!
>
From: chris.aseltine on 28 Aug 2008 10:56
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 28 Aug 2008 12:49
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?

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