libusb claim_interface = reliable BSoD if WinUSB driver is not installed for the device

[brandonros]

bsod-logs.txt

I'm using this as a host: https://github.com/jiegec/usbip on Mac (arm64): $ RUST_LOG=debug cargo run --example host

The device I'm working with is super weird. It is exposing 4 interfaces:

interface_number = 0 transfer_type = Interrupt direction = In
interface_number = 1 transfer_type = Bulk direction = Out
interface_number = 1 transfer_type = Bulk direction = In
interface_number = 2 transfer_type = Interrupt direction = In
interface_number = 3 transfer_type = Bulk direction = Out
interface_number = 3 transfer_type = Bulk direction = In

// get device
let mut device_handle = rusb::open_device_with_vid_pid(vendor_id, product_id).unwrap();
let device = device_handle.device();
// configuration
let config_desc = device.config_descriptor(config_index).unwrap();
device_handle.set_active_configuration(config_desc.number()).unwrap();
device_handle.claim_interface(interface_number).unwrap();
device_handle.set_alternate_setting(interface_number, 0).unwrap();

That device_handle.claim_interface(interface_number).unwrap(); line makes it blow up.

Let me know if the logs are right or if what I am doing just isn't recommended (I can maybe try Windows host -> Windows client if you think it will help)

[vadimgrn]

Hi, the log must contain symbolic names instead of something like 'usbip2_ude+0x1fa6', I can't guess what it was.

[brandonros]

My fault, I did not realize I installed Release instead of Debug, will re-upload, thank you.

[vadimgrn]

Use release build, just follow instructions verbatim.

[brandonros]

are you sure release is ok? no Trace entires in usbip.pdb, etc.

[vadimgrn]

I am sure, WPP tracing is relevant for driver only.

[brandonros]

bsod-logs-2024-01-27.txt

Is this any better?

Step to reproduce:

rem change to your WDK version
set PATH=%PATH%;C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64

set NAME=usbip

tracelog.exe -stop %NAME%-flt
tracelog.exe -stop %NAME%-ude

del /F %NAME%-*.*
tracepdb.exe -f "C:\Program Files\USBip\*.pdb" -s -p %TEMP%\%NAME%

tracelog.exe -start %NAME%-flt -guid #90c336ed-69fb-43d6-b800-1552d72d200b -f %NAME%-flt.etl -flag 0x3 -level 5
tracelog.exe -start %NAME%-ude -guid #ed18c9c5-8322-48ae-bf78-d01d898a1562 -f %NAME%-ude.etl -flag 0xF -level 5

# do the thing that makes the system BSOD, it auto restarts
# upon restart, do not run any extra tracelog commands to stop logs/etc., just run C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe as Admin, open C:\Windows\MEMORY.DMP that BugCheck wrote before BSOD reboot, then run the following commands in WinDbg command line:

!analyze -v
!wdfkd.wdfsearchpath %TEMP%\USBip
!wdfkd.wdfsettraceprefix [%9]%3!04x! %!LEVEL! %!FUNC!:
!wdfkd.wdflogdump usbip2_ude -d
!wdfkd.wdflogdump usbip2_ude -f

# then, copy and paste entire WinDbg.exe output as logs and attach

If this is wrong process please let me know, or if what I am trying is "impossible/broken by design"

[brandonros]

Even after all this when I run !analyze -v again, there are still no debug symbols...?

[vadimgrn]

I don't know what is wrong.I tested release builds, names are present in the log.

[vadimgrn]

Try this sequence, pls

!wmitrace.searchpath +%TEMP%\usbip analyze -v ...

[brandonros]

1: kd> !wmitrace.searchpath +%TEMP%\usbip
Trace Format search path is: 'C:\Program Files (x86)\Windows Kits\10\Debuggers;%TEMP%\usbip'
1: kd> !wdfkd.wdfsettraceprefix [%9]%3!04x! %!LEVEL! %!FUNC!:
SetTracePrefix: "[%9]%3!04x! %!LEVEL! %!FUNC!:"
1: kd> !wdfkd.wdflogdump usbip2_ude -d
Unable to load image \SystemRoot\System32\DriverStore\FileRepository\usbip2_ude.inf_amd64_86c507ba2734a391\usbip2_ude.sys, Win32 error 0n2

Is this expected/the root of our pain?

[brandonros]

I got it, needed to do .sympath+ C:\Program Files\USBip

[brandonros]

https://github.com/vadimgrn/usbip-win2/blob/master/drivers/ude/device_ioctl.cpp#L176

Which variable do we think is causing 0xC0000005 there

[vadimgrn]

Full windbg output is required

[brandonros]

bsod-logs-2024-01-28.txt

[brandonros]

I think you fixed it in https://github.com/vadimgrn/usbip-win2/releases/tag/v.0.9.5.8

[vadimgrn]

Yes, it seems this is the same issue. Have you tried the latest release?

[brandonros]

Yes, working good on this release, thank you.

Device USB\VID_18E1&PID_01B3&MI_02\3&1f679178&2&0002 had a problem starting.

Driver Name: oem24.inf
Class Guid: {fb1cf0c4-b412-451f-9f04-df7537a5003c}
Service: opus_supergoose_plus
Lower Filters: 
Upper Filters: 
Problem: 0xA
Problem Status: 0xC000000D

What would you recommend to trace this down why this is happening? tracelog?

[brandonros]

usbip-ude.txt usbip-flt.txt

[vadimgrn]

It could be unsupported Windows version. Try it on Win11 if you can, please.

[brandonros]

I don't think this is it.

If I do Windows host (https://github.com/dorssel/usbipd-win/releases) to your Windows client (usbip-win2) it is working good.

It is when I try to go Android host or Linux host or Mac OS host (which is using libusb and not "Windows driver implementation") that I run into this issue.

It very well could be "unsupported" but I was looking to figure out why it is unsupported/what is unsupported so I can work around it and fix... :)

[vadimgrn]

I have seen this bug (invalid parameter passed to service or function) when I debugged what is the oldest supported Win version for the driver. The problem is that I didn't get how to find our what API function causes this bug.

[brandonros]

You know what, you are right. They are compiling against Windows SDK 8.1 instead of Windows 10 in the driver.

[brandonros]

Let me ask you this, tell me if I should make a separate issue for this (it might not be in your layer)

pub fn write_slp_command(&self, slp_command: &SlpCommand) {
        let timeout = Duration::from_secs(0); // android host -> usbip-win2 does not work, blocks indefinitely, if i change it to 1 sec it will unblock
        let message = slp::serialize_slp_command(slp_command);
        println!("out: {message:02x?}");
        self.write_device_handle
            .write_bulk(self.out_endpoint_address, &message, timeout)
            .unwrap();
    }

[vadimgrn]

I don't know what it is, but usbip driver must not block indefinitely anyway. I think an IRP just never was completed.