Server restarts when attaching USB device using usbip.exe (non-WSL Windows client)

[T04N]

Hi, I'm encountering a serious issue when trying to use usbipd-win to share a USetup:
Server: Windows machine running usbipd (via dorssel/usbipd-win)

Client: Another Windows machine (not WSL), using usbip.exe to attach the shared USB device.

Problem:
Whenever I attempt to attach the USB device from the client using usbip.exe, the server machine immediately restarts without warning. It seems like a crash or forced reboot.

Command I used on the client:

usbip.exe attach --remote= --busid=

After running this command, the server ( PC ) reboots instantly.
Additional Info:
When I use this prebuilt tool (WSL USB GUI) instead of usbip.exe, the USB attach works perfectly, and the server does not reboot.
This suggests that the issue may be related to how usbip.exe communicates with the server, or perhaps something in the usbipd handling of a non-WSL Windows client request.

Request:
Has anyone experienced similar behavior?

Is there a known issue when using usbip.exe from a regular Windows (non-WSL) environment?
Any idea what could cause the server to restart like this?

Thanks in advance for your help!SB device from my Windows machine.

[dorssel]

You are saying that the machine running usbipd-win reboots when a remote client tries to attach? Is there a blue screen? Does the Windows EventLog say why it rebooted?

[T04N]

You are saying that the machine running usbipd-win reboots when a remote client tries to attach? Is there a blue screen? Does the Windows EventLog say why it rebooted?

I have an issue where the machine running usbipd (acting as the USB server) reboots immediately when a remote client tries to attach a USB device. There is no blue screen and no useful logs in Windows Event Viewer to explain the reboot.

I’m using USBIP version 0.3.6 from this link:
https://github.com/cezanne/usbip-win/releases

However use the client from this project instead:
https://github.com/vadimgrn/usbip-win2,
everything works fine — no crash, no reboot.

It seems the issue only occurs when using the 0.3.6 version from cezanne's repository.

Please let me know how I can further debug or fix this issue.

[dorssel]

usbipd-win itself cannot reboot the system, it is a user mode process. It relays USBIP packets (URBs) to the USB device via the VirtualBox drivers. Drivers of course can reboot the system. It has happened in the past that malformed URBs cause the VBoxUSB driver to crash. But that also leads to a blue screen with a STOP code that helps debugging.

If there is no way to find out the reason for the reboot, from any log, then debugging will be very hard. My guess is that the USBIP client sends a malformed URB, which usbipd-win (user mode, cannot reboot) happily forwards to the VBoxUSB driver (kernel mode, can do everything), which causes the crash.

You could try running usbipd-win in full logging mode (includng PCap), see https://github.com/dorssel/usbipd-win/wiki/Troubleshooting, and hope that the file system flushes before reboot.

[dorssel]

BTW, is the usbip client running on a different physical machine, or on a VM on the same physical machine as the server?

[T04N]

BTW, is the usbip client running on a different physical machine, or on a VM on the same physical machine as the server?

Both the usbip client and the usbipd-win server are running on separate physical machines.

I'm wondering if you could guide me on how to properly set up a usbip client separately, or perhaps provide a download link for the client-side tools? I really appreciate your help with this.

Thanks again!

[dorssel]

No, sorry, I have no experience with Windows clients. Other users have reported success with the two options you mentioned.

[T04N]

Thanks a lot for contributing to the community and helping me with my issue.
I'd like to ask — do you have Discord or any other way I could contact you? I'd really appreciate the chance to learn more from you.

No, sorry, I have no experience with Windows clients. Other users have reported success with the two options you mentioned.