Include INF and CAT for WinUSB install

[brianddk]

The windows bridge installer should also install the INFs to associated the TREZOR device (vid:1209, pid:53c1, rev:0100, class:ff, mi:00) with the Microsoft WinUSB.sys driver. On some revisions of Windows this association is not made and the the device is left in error in the PNP database (aka. "yellow bang"). The Zadig installer can fix this and "unbang" the device, but does so by installing auto generated certificates into the user's certificate store.

Including an INF and signed CAT is standard for windows driver installations, even when said drivers are part of the base OS.

[karelbilek]

What is done here is basically the same as zadig.

Zadig actually uses libwdi (see zadig source) - what is done here is the same as zadig - this builds libwdi, this uses its wdi-simple.c, the functions are called exactly the same way zadig calls them.

What that does is indeed adding and installing auto-generated certificates into the certificate store.

It should be working in any Windows installation where zadig is working, because here the installer does exactly the same thing zadig is doing, including the auto-generated INFs. Can you write where exactly zadig helps, but the installer here doesn't work? (Which configuration?)

[karelbilek]

I am not working at Trezor anymore, but when I was, we spent a lot of time debugging all kind of Windows 7 devices, and in the end we get this installer working on all Windows 7 instances we could find :D

it's possible we still have some issues somewhere though.

We use libwdi (zadig library) only on win7. Windows 8 and windows 10 have winusb included so we don't use the zadig installer there.

[brianddk]

Neither my Windows 10 install nor any of my Windows Server 2019 installs associated winusb with Trezor. Only way I could get these installs to work was to run the zadig utility.

Since the documentation said the Zadig utility is required, I assumed this was by design, but it sounds like you expect builds beyond Windows 7 to work out of the box. I'll try spinning up a Windows 8 (client) VM to see what happens.

The Dev team might want to look at the Windows vNext since its possible that Microsoft is beginning to prohibit the type of magic that libwdi performs. Technically speaking, KMDF drivers running against self-signed certs is rather taboo. Though it sounds like the intent is to only do this magic on Windows 7, so my warnings are rather circular.

Can you suggest some log files or certificate artifacts I should look for when doing some Win8 VM testing?

[karelbilek]

Huh, interesting.

According to this documentation (on wiki site of libwdi, author of zadig :)), WCID devices should work out-of-the-box with windows 8 and windows 10, and it did so on all my testing

https://github.com/pbatard/libwdi/wiki/WCID-Devices#what-is-wcid

[karelbilek]

Also
https://pete.akeo.ie/2011/10/on-windows-8-and-wcid-devices.html

By the way. Because we did a lot of debugging on windows 7 devices (there were tons of issues), we added a detailed log into bridge status. It's at http://127.0.0.1:21325/status/ , and clicking (on windows) on "detailed log" gives you really detailed log of all the USB peripherals and all the system errors. It helped us A LOT when debugging windows 7 USB issues.

But it also gives you a lot of identifying data, since it really lists everything about the computer.

So you should look there, but be careful before posting it here, the log is VERY detailed.

[brianddk]

I'm beginning to suspect VirtualBox. I just found a post of another user from last year complaining about WinUSB devices not passing through.

https://forums.virtualbox.org/viewtopic.php?t=87351

[karelbilek]

What is the host PC? If it's linux, maybe you need udev rules to allow the VBox to get USB devices.

(I remember when I tried it, I gave up on setting udev to work with vbox, and just run virtualbox as a root, but don't tell anyone :D )

[karelbilek]

Yes, the windows 7 self-signed thing is needed only on windows 7. (And only on windows 7 with Windows Update turned off, but it turns out it's about 50% of installations :D )

[brianddk]

Host is Windows 10, Guest was Windows 2019, but I'm now finding multiple reports of failure for WinUSB on VirtualBox. The consensus is to switch to VMWare Player for the best WinUSB support. I'll give it a shot and report back

[karelbilek]

It's interesting, btw, that zadig helps in the virtualbox guest machine. I wonder why...

[karelbilek]

Just off the wall idea... do you have the VirtualBox extension pack? It adds support for USB2.0 and USB3.0 devices. Maybe that's needed?

[karelbilek]

I can't replicate this, just tried.

Host machine Windows 7 (all I have here), with zadig drivers (although it probably doesn't matter); guest machine Windows 10, I intentionally just used USB 1 controller (=not the extension pack) and everything worked out of the box.

[karelbilek]

If this is replicable in your virtualbox, will you provide the detailed log from the virtualbox from bridge? (I think that, if you use fresh VM, the detailed log should not have any information, but check it before posting here)

If not, can I close this?

[brianddk]

Closing as a likely virtualbox only issue. There are known issues in virtualbox with WinUSB

[SomberNight]

I have also run into this now.
On fresh Windows 10 1809 guest VM using VirtualBox 6.0.8, Trezor Bridge does not see Trezor One device.
Host machine is also running Win10.

After installing WinUSB driver through Zadig, the Bridge now sees the device.

[brianddk]

To be fair, Oracle has a long history of messing up webusb support.

https://forums.virtualbox.org/viewtopic.php?t=83055

[tarsonis123]

I wonder why there is no driver included as after being affected by this issue I found a lot users on reddit having the same issues with drivers. I'm not speaking of using it in a VW. All those support request found no real solution but just one having a wrong cable...

My workstation has a AMD B350 chipset with WIN10 and now as of today WIN11. The device worked once several month ago on this machine. Since then I'm trying to find a solution to get it working again. There are no conflicts in the driver details. Still Trezor software refuses to see the device...
The support is clueless. "change the cable type of solutions" even if I said it works on a laptop with the same cable.
Bootloader mode isn't recognized either.

Zadig drivers did not solve the issue.
On the laptop it is the driver version 10.0.19041.1
On the workstation it is 10.0.22621.608

What I have done already which should show that this can't be ideally to let the customer go through this for a "security and trust" device kind of product.

• tested all 8 available usb ports

• tested a different USB cable

• started the Suite and bridge app as administrator

• used incognito mode / no cache issue

• created a new Windows account and tested it there

• disabled firewall

• checked group policy

• updated chipset drivers (b350 chipset here)

• tried to install the laptop WINUSB.inf driver where the T works, but I'm not allowed to install it on the other machine

• deleted the device and reinstalled the driver several times

• followed the step in the docs (https://trezor.io/support/a/trezor-suite-doesn-t-see-my-device) with the Zadig software to replace to libusb0 (v1.2.6.0) driver - tested all driver with no success

• updated Win10 to 11

• I have reinstalled suite / bridge more than 5 times now. Problem persists

Latest log of the bridge:

2.0.27
Driver log
Connected devices:
USB\VID_1209&PID_53C1\6D01DD7E437832E1114FC24C
Driver installed from C:\WINDOWS\INF\usb.inf [Composite.Dev]. 1 file(s) used by driver:
C:\WINDOWS\system32\DRIVERS\usbccgp.sys
Name: USB-Verbundgerät

USB\VID_1209&PID_53C1&MI_00\7&2A842FBB&5&0000
Driver installed from C:\WINDOWS\INF\winusb.inf [WINUSB]. 1 file(s) used by driver:
C:\WINDOWS\system32\DRIVERS\winusb.sys
Name: TREZOR Interface

USB\VID_1209&PID_53C1&MI_01\7&2A842FBB&5&0001
Driver installed from C:\WINDOWS\INF\input.inf [HID_Inst]. 3 file(s) used by driver:
C:\WINDOWS\system32\DRIVERS\hidusb.sys
C:\WINDOWS\system32\DRIVERS\hidclass.sys
C:\WINDOWS\system32\DRIVERS\hidparse.sys
Name: USB-Eingabegerät

Disconnected devices:
USB\VID_1209&PID_53C0\000000000000000000000000
Driver installed from C:\WINDOWS\INF\winusb.inf [WINUSB]. 1 file(s) used by driver:
C:\WINDOWS\system32\DRIVERS\winusb.sys
Name: TREZOR

[sime]

Related reddit post: https://www.reddit.com/r/TREZOR/comments/yhebte/trezor_refuses_to_connect_with_suite_trezorio/

The version of bridge you are reporting is the standalone version. Trezor Suite bundles a newer version (2.0.31) which is not released as standalone.

Can you share what Trezor bridge reports when the bundled bridge is used. i.e. shutdown standalone bridge, open suite and visit http://127.0.0.1:21325/status/

[tarsonis123]

Yes I have all sorts of situation tested as I was running out of ideas what else to try. Last try was getting rid of all Trezor related data and install an older version (Trezor-Suite-22.9.3-win-x64) without the standalone bridge. I could once get the device connected with the Suite App, but after disconnecting it, I had the same issue again.

I could since then not reconnect it again. What I've done before is to install the lib 1.26 driver, deinstall the device again and let windows install its driver again. This seems to be related to the temporary success as it was the same with a VM with Win10 that I installed to see if I can get it running there at least.
And the device connects correctly with the Suite on my VW Win10 version on the same machine where the host OS Win11 refuses to connect the Suite with the device.. So the VM OS connects to the device correctly while the host OS is refusing to connect Suite and the device which lets me think it is not driver related..

So here. No standalone bridge like yesterday Trezor-Suite-22.9.3-win-x64. I have it installed for all users in the programs folder.

2.0.31 (rev 5f53132)
devcon.exe does not exist
...
GET /status/
POST /listen
127.0.0.1 - - [31/Oct/2022:20:37:54 +0100] "POST /enumerate HTTP/1.1" 200 3
POST /enumerate
127.0.0.1 - - [31/Oct/2022:20:37:54 +0100] "POST / HTTP/1.1" 200 41
POST /

//EDIT:

Ok. I uninstalled the Suite and deleted Appdata again. So it seems uninstalling the Suite and installing again I'm able to connect with the device. Once I disconnect the device, I never can reconnect it again. Too me this looks like an App issue not an driver/windows issue

[sime]

Before and after Appdata clearing does bridge show a connected device? What about the web version of suite in Chrome. It uses WebUSB when bridge is not available: https://suite.trezor.io/web

Are you on Model T? This month we're planning to release a USB data connection feedback in the firmware and a new version of bridge bundled with Trezor Suite.

[tarsonis123]

Yes, once I make a fresh install (appdata cleared - revo uninstaller reg clean) the bridge is showing the device and the standalone suite app shows the pin dialog. When I disconnect the device (safely with win prop or just pulling it) and reconnect it again, whether the bridge nor the Suite App ever sees the device again. Tested it 4 times now. It is reproducible.

This is the model 1 here. Same issue with the webversion from your link:

Log of the webversion:

[
  {
    "environment": "web",
    "suiteVersion": "22.10.3",
    "commitHash": "540db5426ce88c33bdda2fdae0ceb50f6cbc4a23",
    "startTime": "Wed, 02 Nov 2022 17:23:00 GMT",
    "isDev": false,
    "debugMenu": false,
    "online": true,
    "browserName": "chrome",
    "browserVersion": "106.0.0.0",
    "osName": "windows",
    "osVersion": "10",
    "windowWidth": 1607,
    "windowHeight": 1082,
    "screenWidth": 3440,
    "screenHeight": 1440,
    "earlyAccessProgram": false,
    "language": "en",
    "autodetectLanguage": true,
    "platformLanguages": "en-DE",
    "theme": "dark",
    "autodetectTheme": true,
    "localCurrency": "usd",
    "discreetMode": false,
    "tor": false,
    "torOnionLinks": true,
    "labeling": "",
    "analytics": true,
    "instanceId": "[redacted]",
    "sessionId": "[redacted]",
    "transport": "WebUsbPlugin",
    "transportVersion": "",
    "rememberedStandardWallets": 0,
    "rememberedHiddenWallets": 0,
    "enabledNetworks": [
      "btc"
    ],
    "customBackends": [],
    "devices": [],
    "wallets": []
  },
  {
    "type": "@suite/set-theme",
    "datetime": "Wed, 02 Nov 2022 17:23:00 GMT",
    "payload": {
      "variant": "dark"
    }
  },
  {
    "type": "@suite/online-status",
    "datetime": "Wed, 02 Nov 2022 17:23:00 GMT",
    "payload": {
      "status": true
    }
  },
  {
    "type": "@suite/set-language",
    "datetime": "Wed, 02 Nov 2022 17:23:00 GMT",
    "payload": {
      "locale": "en"
    }
  },
  {
    "type": "@suite/tor-status",
    "datetime": "Wed, 02 Nov 2022 17:23:00 GMT",
    "payload": {
      "status": "Disabled"
    }
  },
  {
    "type": "@router/location-change",
    "datetime": "Wed, 02 Nov 2022 17:23:00 GMT",
    "payload": {
      "pathname": "/web/onboarding",
      "app": "onboarding"
    }
  },
  {
    "type": "transport-start",
    "datetime": "Wed, 02 Nov 2022 17:23:03 GMT",
    "payload": {
      "type": "WebUsbPlugin",
      "version": ""
    }
  },
  {
    "type": "@router/location-change",
    "datetime": "Wed, 02 Nov 2022 17:23:17 GMT",
    "payload": {
      "pathname": "/web/settings",
      "app": "settings"
    }
  },
  {
    "type": "@modal/open-user-context",
    "datetime": "Wed, 02 Nov 2022 17:23:19 GMT",
    "payload": {
      "type": "application-log"
    }
  }
]