Hello,
This will probably end up being more of a userspace question, but:
It is a popular solution for device bootloaders to connect and
disconnect a device rapidly that a program is waiting for (instead of
using the DFU class). In this case the device registers a virtual COM
port, but the COM port GUID when registered for WM_DEVICECHANGE
messages is not catching the device registration like it does a FT232
and so on.
How can I find the class GUID? There’s no way to make the device
persist in this state. I have full control over this device save the
boot ROM can not be edited.
I can see in my update log where the driver was installed, but
clicking the message directs me to a webpage instead of giving me
information on the driver.
Cheers,
R0b0t1
On May 29, 2018, at 9:55 PM, xxxxx@gmail.com wrote:
>
> It is a popular solution for device bootloaders to connect and
> disconnect a device rapidly that a program is waiting for (instead of
> using the DFU class). In this case the device registers a virtual COM
> port, but the COM port GUID when registered for WM_DEVICECHANGE
> messages is not catching the device registration like it does a FT232
> and so on.
Are you saying USB device A is created, driver A is loaded, driver A loads a ROM image, the device detaches and reconnects as device B, and that device comes up with a COM port?
Does the device show up with a different VID/PID initially? Does it use a different driver?
> How can I find the class GUID? There’s no way to make the device
> persist in this state. I have full control over this device save the
> boot ROM can not be edited.
You should be able to see this happen in \windows\inf\setup.dev.log. If it has an INF, you can go look at the INF to find the class GUID. If it’s a standard driver, it should be possible to figure this out.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Wed, May 30, 2018 at 1:38 AM, xxxxx@probo.com wrote:
> On May 29, 2018, at 9:55 PM, xxxxx@gmail.com wrote:
>>
>> It is a popular solution for device bootloaders to connect and
>> disconnect a device rapidly that a program is waiting for (instead of
>> using the DFU class). In this case the device registers a virtual COM
>> port, but the COM port GUID when registered for WM_DEVICECHANGE
>> messages is not catching the device registration like it does a FT232
>> and so on.
>
> Are you saying USB device A is created, driver A is loaded, driver A loads a ROM image, the device detaches and reconnects as device B, and that device comes up with a COM port?
>
> Does the device show up with a different VID/PID initially? Does it use a different driver?
>
>
No, rather: masked ROM on the chip configures the device to be a COM
port, device A, which accepts commands to access bulk device storage;
device is later reset and comes up as device B.
I couldn’t initially even grab the PID/VID, I eventually did so by
catching GUID_DEVINTERFACE_USB_DEVICE events with WM_DEVICECHANGE. For
the brief amount of time that the device was in Device Manager it was
definitely a COM port.
>> How can I find the class GUID? There’s no way to make the device
>> persist in this state. I have full control over this device save the
>> boot ROM can not be edited.
>
> You should be able to see this happen in \windows\inf\setup.dev.log. If it has an INF, you can go look at the INF to find the class GUID. If it’s a standard driver, it should be possible to figure this out.
This will be useful information, thank you. Per above I did finally
catch the device with WM_DEVICECHANGE. It also shows up as a port now.
I have no idea what is different, sorry for the list noise.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>