mcuee

> @mcuee should I change the author to me to pass the CI? or is this being held because of another reason? Please help to fix the CI build. https://ci.appveyor.com/project/LudovicRousseau/libusb/builds/51677608...

@sonatique I am fine with the idea of this PR. I am not good at reviewing code changes like this PR. But since you and @seanm have reviewed the code...

No issues under MSYS2 UCRT64. ``` UCRT64 /c/work/libusb/libusb_pr1617 $ make check Making check in libusb make[1]: Entering directory '/c/work/libusb/libusb_pr1617/libusb' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/c/work/libusb/libusb_pr1617/libusb'...

> > @mcuee @tormodvolden @hjelmn : what do you think? Ready to give your approval? > > I think it would be good to have at least one more approval...

> [@mcuee](https://github.com/mcuee) this is not a question. 99% is a bug. We will update the label if it is confirmed to be a libusb bug.

Please help to try out the libusb Windows hotplug PR to see if the issue is there or not. * https://github.com/libusb/libusb/pull/1406

@sonatique Just wondering if you can accomodate the following PR for testing. * https://github.com/libusb/libusb/pull/1498

> [@mcuee](https://github.com/mcuee) : sorry, what do you mean exactly? Would you like me to test this PR within the context of the new hotplug PR? Or is it related to...

> Edit: anyway I did it and it was easy. I see things working as expected. I guess the idea is to leave hotplug_fallback as is, I mean: not playing...

@fabiensanglard Going back to the existing issue, could you post the debug log with current git head? It may also be interesting to post the debug log with PR #1633....