UsbDk_StartRedirect hangs if no normal USB driver using UsbDk V1.00-22

[gwgill]

UsbDk_StartRedirect hangs reliably on my Windows 10 22H2 build 19045.3448 system with a USB device that has no normal USB driver associated with it. It hangs for exactly 2 minutes and then UsbDk_StartRedirect returns failure.
A control-C doesn't terminate the program that has hung.
Re-plugging the device triggers the UsbDk_StartRedirect to return with success.
With a USB driver associated with the device, UsbDk_StartRedirect doesn't hang.
While hung, hiding the device with UsbDkController.exe doesn't resolve the hang.
If the device is hidden before it is plugged in, UsbDk_StartRedirect doesn't hang.

A WdfLogDump is attached.
A TraceView trace is attached.
hang.txt
UsbDkTrace.etl.zip

[gwgill]

It appears that if a device doesn't have a normal driver associated with it, it gets marked as having a driver install error (28) and then on IOCTL_INTERNAL_USB_CYCLE_PORT the device disappears and is not returned.
The only way of preventing this I found is to mark the device as RawDeviceOK.
To do this, a filter has to be attached to such devices that sets the RawDeviceOK flag in IRP_MN_QUERY_CAPABILITIES.
Ideally such a filter isn't attached to devices that have a normal driver.
It doesn't seem possible to determine if a device has a normal driver or not using conventional means (i.e. IoGetDeviceProperty() or IoOpenDeviceRegistryKey() to see if there is a Driver or Service value), because the PDO is not valid within IRP_MN_QUERY_DEVICE_RELATIONS.
The only workaround to this appears to be to locate the Registry Enum/USB entries for VID/PID devices, and read the Driver or Service value that way.
Devices that are marked Raw and have a corresponding Enum won't switch to using a normal driver if it is installed after the device is first plugged in. A workaround for this is to set the CONFIGFLAG_REINSTALL flag in the devices ConfigFlags value within its Registry Enum on the device being unplugged.
I've added code to do all this in the UsbDk branch here https://github.com/gwgill/UsbDk

[gwgill]

After further testing, it seemed that there was no reliable solution to the problem of using UsbDk to drive devices without a conventional driver. While the workaround of adding a filter driver and marking the device RawDeviceOK works for many devices, the hub port CYCLE used by UsbDk was not reliable for some combinations of devices and hubs. Such combinations results in a failure to read the correct VID/PID from the device, returning VID_0000&PID_0002 instead.

After considerable trial and error efforts, it seems that these difficult devices can indeed be made to work if they are configured and their hub port reset before doing a hub port CYCLE. The code to do this and finesse several other aspects of using UsbDk to drive a device without a conventional function driver is present in my fork of UsbDk .