Windows 10 Xbox 360 (Wired) controller not working about usbip-win

[cezuni]

@rebootjac : Usbip on android is interesting! Anyway, your issue seems to be related to usbip version mismatch. Please, check old issues #3 and #6.

[Oxalin]

Same as for #30 , I'll ask around if someone could lend me a Xbox 360 controller.

[jacopomaroli]

Hey I'm just chiming in to say I'm experiencing the same issue with a wireless controller adapter.
Same error message of the OP.

I tried the same driver he reported (https://sourceforge.net/projects/usbip/files/usbip_windows/) it worked but it threw a BSOD when I did run the detach.

The version I compiled and the version I downloaded from the release page are just showing the above issue on binding. Let me know if I can help investigating. :)

[cezuni]

@jacopomaroli : What is your usbip server ? I think that usbip server of android app is not compatible to usbip-win.

[jacopomaroli]

Hi @cezuni ! I'm using a raspberry pi with usbip server compiled from this source https://github.com/raspberrypi/linux/tree/rpi-4.19.y/tools/usb/usbip
I can attach other peripherals like usb sticks (storage devices) but I'm getting this error with the 360 wireless controller adapter

[koudis]

@jacopomaroli

Small question - did you build the USBIP vhci driver under Debug or Release configuration? Did you build vhci driver on the client system? Did you try to update env. to newest SDK and WDK?

If you built usbip vhci driver under Debug conf the driver may not work good in other kernel versions or other systems (systems which has no WDK etc.)....

[jacopomaroli]

@koudis I'm running the driver on the same windows 10 machine which was used to build it in debug x64 and release x64 configs (yes, I spent a bit of time fixing the release config to see if I could produce a working driver)

I also tried to apply your patch here #43 just in case since I saw in regedit that Pid/PID was creating two different entries depending if I was attaching the adapter to the usb directly or using usbip-win

I set 10.0.17134 version of WDK and SDK for every project in the solution

problem persist

[cezuni]

@jacopomaroli:

I also tried to apply your patch here #43 just in case since I saw in regedit that Pid/PID was creating two different entries depending if I was attaching the adapter to the usb directly or using usbip-win

Is an old registry entry(Pid or PID) removed if an usb device is attached in a different way?

[jacopomaroli]

@cezuni The old entry is removed when the driver is replaced/uninstalled. It stays there if I plug it in directly after using usbip or vice versa. I'm referring to the entry in \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{d61ca365-5af4-4486-998b-9db4734c6ca3}\%insert_entry_number_here%
I have two entries there now

I realised there were few other capitalisation issues around the code:
"Rev" on the same line here
https://github.com/cezuni/usbip-win/pull/43/files#diff-3275dd12bb154f0cbf7f1e0abdad8f0eR250

and hex code should be capitalised as well, as in:
RtlStringCchPrintfW(ids_hw, 31, L"USB\\VID_%04hX&PID_%04hX&REV_%04hX", vpdo->vendor, vpdo->product, vpdo->revision);

anyway driver still throw same error. I think it might be intersting if we look at the driver events:

*** usbip ***

Device USB\VID_045E&PID_0719\1&1aafb3d5&6&0001 was configured.

Driver Name: xusb22.inf
Class Guid: {d61ca365-5af4-4486-998b-9db4734c6ca3}
Driver Date: 09/14/2018
Driver Version: 10.0.17763.1
Driver Provider: Microsoft
Driver Section: CC_Install
Driver Rank: 0xFF0001
Matching Device Id: USB\VID_045E&PID_0719
Outranked Drivers: oem54.inf:USB\VID_045E&PID_0719:00FF0001 usb.inf:USB\COMPOSITE:00FF2003
Device Updated: false
Parent Device: ROOT\UNKNOWN\0000

------------------------------------

*** direct ***

Device USB\VID_045E&PID_0719\FE097BC0 was configured.

Driver Name: xusb22.inf
Class Guid: {d61ca365-5af4-4486-998b-9db4734c6ca3}
Driver Date: 09/14/2018
Driver Version: 10.0.17763.1
Driver Provider: Microsoft
Driver Section: CC_Install
Driver Rank: 0xFF0001
Matching Device Id: USB\VID_045E&PID_0719
Outranked Drivers: oem54.inf:USB\VID_045E&PID_0719:00FF0001
Device Updated: true
Parent Device: USB\VID_0424&PID_2514\5&2e17f6d0&0&1

we can see the controller being identified as Device USB\VID_045E&PID_0719\1&1aafb3d5&4&0001 in case of a direct attachment or Device USB\VID_045E&PID_0719\FE097BC0 when using usbip.
Is it relevant?
what's that hash after the vid/pid?

[cezuni]

@jacopomaroli :

we can see the controller being identified as Device USB\VID_045E&PID_0719\1&1aafb3d5&4&0001 in case of a direct attachment or Device USB\VID_045E&PID_0719\FE097BC0 when using usbip.
Is it relevant?
what's that hash after the vid/pid?

Maybe pnp manager generated that? Different hex styles may imply that both cases are handled differently. One evidence is that when the controller is attached via usbip, the device is not recognized as a composite device. (Note outranked drivers fields in your logs) It is very likely that usb identifiers are different. Can you compare usb identifiers for both cases ? You can find those identifiers in device manager.

[jacopomaroli]

@cezuni I'm sorry, I did another test and I just realised I must have swapped the outputs. I updated the above comment to reflect the actual status of the configuration to avoid confusion.
I hope it makes more sense now :)
I also added the usb identifiers you were asking for. Let me know if you need any other info

[cezuni]

@jacopomaroli : From your corrected description, usbip-win rather treats the device as composite.

I also added the usb identifiers you were asking for. Let me know if you need any other info

I want to know compatible IDs for both cases. Maybe usbip-win seems to deliver USB/COMPOSITE as one of compatible IDs to the PNP manager.

[jacopomaroli]

@cezuni the followings are the compatible IDs for both cases

*** usbip ***
USB\Class_FF&SubClass_FF&Prot_FF
USB\Class_FF&SubClass_FF
USB\Class_FF
USB\COMPOSITE

*** direct ***
USB\Class_FF&SubClass_5D&Prot_81
USB\Class_FF&SubClass_5D
USB\Class_FF

I also did a couple of tries and hardocded the parameters in the driver code in the setup_vpdo_compat_ids function in order to have the same compatible id that I have when I connect the controller normally but I got the same problem

[cezuni]

@jacopomaroli : The reason why both methods gives different compatible ids should be investigated later. The more disappointing thing is that the problem still exists after your workaround. Can you share the windows kernel log obtained in the condition that usbip-win provides the same compatible ids in hardcoded style?

[jacopomaroli]

Yeah, sure! Is this a good how-to in order to achieve what we need? https://www.itprotoday.com/microsoft-visual-studio/wpp-tracing-visual-c-2010-projects with this uuid 8b56380d-5174-4b15-b6f4-4c47008801a4 . If not can you post a better source?

[cezuni]

@jacopomaroli : I don't know wpp tracing. I look forward your detailed explanation for wpp tracing.

Let me tell my method. usbip-win uses DbgPrintEx API for kernel logging. DebugView is a good tool to view the logs. Before using it, you should enable debug filter by creating a DWORD registry entry(path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter\IHVDRIVER , value: 0xffffffff). Restart is required. Refer this link.

Another good candidate is WinDbg. This tool can monitor logs on a remote machine. I resolve a BSOD by using WinDbg via serial communication. Of course, target/development machines are all virtual machines.

[jacopomaroli]

thanks for the info @cezuni ! There you go: these are the logs of the driver version where I'm forcing subclass to 0x5d, protocol to 0x81 and remove USB\composite to match the case where I plug the adapter directly. Also capitalisation of the driver ids is fixed.

logs.txt

I'm not an expert but I suspect something was unhappy around here...

[...]
00000137	0.04950790	usbip_vhci: process_irp_urb_req: function: URB_FUNCTION_GET_STATUS_FROM_DEVICE	
00000138	0.04951120	usbip_vhci:(WW) process_irp_urb_req: unhandled function: URB_FUNCTION_GET_STATUS_FROM_DEVICE: len: 136	
00000139	0.04951540	usbip_vhci: vhci_internal_ioctl: Leave: STATUS_INVALID_PARAMETER
[...]

[jacopomaroli]

Since I was blocked I had the Idea to try previous versions and very interesting things happened making the adapter work or breaking it. This is the order of the versions I tested (it helps to follow if you go to the github /commits page):
fc79b7b 01/07/2019: does not work. No bsod on detach
28bf3b9 05/05/2018: it works but bsod on detach
10b9dcb 11/07/2018: it works but bsod on detach
351b0ed 12/08/2018: it works. No bsod on detach
5bf18d1 27/02/2019: does not work. No bsod on detach
393ac6a 27/01/2019: does not work. No bsod on detach
(At this point I tried few versions between 351b0ed and 5bf18d1 all not working and no bsod)
351b0ed 12/08/2018 (again): this time does not work. No bsod on detach.

The point I’m trying to make is that it seems there are some versions which are broken and leave the system in broken state, other which are working but not able to recover from broken state, and other which are working and able to recover from broken state.
I’ll keep trying to install and unistall versions beetween those commits to find the offending one but if you have some specific ones which I should try to speed up the process please shout.

[cezuni]

@jacopomaroli : A long text log can be attached as a file. You can find a help message in the bottom of github comment window. Anyway, thanks for your log.

The warning for URB_FUNCTION_GET_STATUS_FROM_DEVICE is worth to investigate. But the warning may be negligible because the next usbip command(seq:5) was successfully processed. Was there any more logs? The log seems to have more logs after 190 line. IRP_MN_REMOVE_DEVICE at 189 line means that usbip session was disconnected and usually more logs appear after such a log.
For a more concrete clue, more detailed logs will be needed. Can you share another logs obtained from a forwarding routine and a linux usbip server? Please refer #44 (comment) and #44 (comment) .

[cezuni]

@jacopomaroli: Your testing versions and results are great but diff from two commits are so large. So I give up to find the problem from diff.

[jacopomaroli]

@cezuni thanks for pointing that out, I edited my comment to include the logs as an external file.

While working on the commit diff lead, I made a small script which compiles all the version between two git hashes. I now have 88 versions of the driver to play with, going back and forth, to find the offending one :)
I share the script here because I think it's interesting and can save some time to other people willing to troubleshoot similar problems

https://gist.github.com/jacopomaroli/36639202f47331412139869c812d3c75

I'll try to do what you suggested in the above comment in the next few days
thanks

[cezuni]

@jacopomaroli : Did you check up-to-date version? Recent uploaded commits may resolve this issue.

[jacopomaroli]

hey @cezuni thanks for the heads up. I tried the new version but it fails the exact same way. I'll try to gather those logs as soon as I have time these days

[cezanne]

Too old issue. Close.