Skip to content

GUIDE.md

Latest commit

 

History

History
213 lines (133 loc) · 10.7 KB

GUIDE.md

File metadata and controls

213 lines (133 loc) · 10.7 KB
Raw

Step-by-Step Guide — What each script does and why

This guide walks through the diagnostic and fix scripts in the order they should be run. It is intentionally verbose. If you just want the fix, see QUICKSTART.md instead.

Background: what's a Bluetooth USB device, really?

A Bluetooth USB dongle like the BT60 is, at the hardware level, just a USB device that speaks the Bluetooth Host Controller Interface (HCI) protocol. USB devices are identified by a 4-hex-digit Vendor ID (VID) and Product ID (PID). The BT60 reports VID=0x33FA, PID=0x0001.

When you plug the BT60 in, Windows performs a process called enumeration:

  1. The USB hub detects a new device attached.
  2. The USB driver stack reads the device's descriptors.
  3. The descriptors tell Windows: "I'm a USB device, my class is 0xE0 (wireless controller), my subclass is 0x01 (radio frequency), my protocol is 0x01 (Bluetooth)."
  4. Windows builds a list of compatible IDs: USB\Class_E0&SubClass_01&Prot_01, USB\Class_E0&SubClass_01, USB\Class_E0.
  5. Windows searches its driver store for a driver that matches.
  6. If a driver is found, Windows loads it and assigns the device a class GUID based on what the driver declares.

For a Bluetooth device, the class GUID should be {e0cbf06c-cd8b-4647-bb8a-263b43f0f974} (Bluetooth radio). The driver should be BTHUSB (Microsoft's built-in Bluetooth USB driver).

If something goes wrong at step 5 or 6, you get one of two problems:

  • The device shows up as a generic USB device (class GUID {36fc9e60-c465-11cf-8056-444553540000}) with no Bluetooth functionality.
  • The device shows up as a Bluetooth device but the driver fails to initialize, leaving it with a red X in Device Manager and ProblemCode 31 (CM_PROB_FAILED_ADD).

Both happen with the BT60. The fix addresses both.

Phase 1: Diagnostics

bt60_diag.ps1 — capture initial state

This script is read-only. It just looks at your system and reports what it finds. Run it first to confirm your problem matches what this repo solves.

What it reports:

  • All Bluetooth-related services and their status
  • All Bluetooth-class devices and their status
  • All USB devices with a non-OK status (the problem devices)
  • Driver installation policies (whether Windows is configured to block or allow driver installs)
  • Code integrity policy (whether Secure Boot is blocking unsigned drivers)
  • Recent system events from BTHUSB and Bluetooth providers
  • Recent setupapi.dev.log entries mentioning Barrot
  • Driver store contents (which INFs are cached)
  • The actual brbtusb.sys, bthusb.sys, bthenum.sys files on disk

What you're looking for in the output:

  • A device named "BARROT Bluetooth Adapter" or "BRTLink Bluetooth Device" with Status=Unknown or Status=Error.
  • The class GUID for that device is NOT {e0cbf06c-cd8b-4647-bb8a-263b43f0f974} (it's {36fc9e60-c465-11cf-8056-444553540000} instead).
  • A brbtusb.inf_amd64_* directory in the driver store.
  • A btath_a2dp.sys, btathrcp.sys, qcacldservice\Qca61x4rampatch.sys file marked MISSING in C:\Windows\System32\drivers\.

If you see all of that, you have the exact problem this repo fixes.

Phase 2: Remove ghost devices

When a USB device is unplugged and replugged into a different port, Windows does NOT cleanly remove the old device instance. It leaves "phantom" devices in the registry. After several replugs, you can have 4-5 entries for the same physical BT60, each with a different "hub path."

The phantoms don't directly cause the problem, but they confuse the driver search process. Windows might pick a driver based on a stale entry.

bt60_recover.ps1 — remove phantoms and add Barrot driver

This script:

  1. Lists all devices with VID 0x33FA (Barrot) and VID 0x0A12 (BRLINK, an OEM rebranding of Barrot).
  2. Calls pnputil /remove-device on every non-OK instance.
  3. Re-adds the brbtusb.inf driver package to the driver store (in case it was removed by a Windows Update).
  4. Restarts the bthserv and BthAvctpSvc services.
  5. Triggers a hardware rescan.

What you should see after: the device count for VID 0x33FA drops to 1 (or 0 if the BT60 is unplugged).

Phase 3: Diagnose the driver binding

bt60_check.ps1 — verify driver binding state

This script:

  1. Lists all Barrot devices and their driver bindings.
  2. Lists all Bluetooth class devices and their status.
  3. Checks Bluetooth services.
  4. Looks at the system log for recent BTHUSB events.

What you're looking for:

  • The Barrot device has Driver: {36fc9e60-c465-11cf-8056-444553540000}\0008 and INF: oem19.inf (or oem14.inf or oem28.inf).
  • The bthenum.sys (Bluetooth enumerator) has 0 child devices for the Barrot.
  • The system log shows BTHUSB event ID 5 or 6 (HCI errors or "only one active adapter").

Phase 4: Force radio enable

bt60_force.ps1 — try enable/restart on stuck children

Sometimes a child BTHBRB device gets stuck in Status=Unknown with a CM_PROB_PHANTOM. This script tries pnputil /enable-device and pnputil /restart-device on each one, and on the parent Barrot device.

This often fails because the underlying issue (the Barrot driver being a lower filter on BTHUSB) hasn't been addressed. But it's worth trying as a first attempt.

Phase 5: Registry inspection

bt60_radio.ps1 — inspect and clear ConfigFlags

The ConfigFlags value in a device's enum key is a bitmask. Bit 0 (0x1) means "disabled by user." Bit 1 (0x2) means "failed to install." Bit 6 (0x40) means "config failed."

If ConfigFlags=0x1 is set, the device is permanently disabled in the registry. This is the "Windows auto-block" the user observed — even after a clean driver install, the device is blocked at the registry level.

This script:

  1. Reads the ConfigFlags value for the Barrot device.
  2. Sets it to 0 (un-block).
  3. Triggers a hardware rescan.

If the device works after this, the original problem was just a stale ConfigFlags value. If not, you need the full driver replacement.

Phase 6: Driver replacement

bt60_fix.ps1 — uninstall Barrot driver, force BTHUSB binding

This script:

  1. Calls pnputil /stop-service and pnputil /delete-driver to remove the Barrot driver.
  2. Calls pnputil /remove-device to remove the Barrot device instance.
  3. Prompts the user to unplug and replug the BT60.
  4. After replug, checks what driver Windows bound to the device.

If Windows bound BTHUSB correctly, the device is fixed. If it bound brtlinkusb (the Barrot driver) again, the script falls back to:

  • Setting Service=BTHUSB directly in the device's registry enum key.
  • Removing UpperFilters and LowerFilters.

The registry override is what makes this work. Windows will now load BTHUSB instead of brtlinkusb for this specific device instance.

Phase 7: Cleanup

bt60_clean.ps1 — remove all Barrot driver packages

This script enumerates all installed oem*.inf packages, finds the ones with "Barrot" in the provider name, and deletes them. It also verifies that brbtusb.inf is gone from the driver store.

After this, the Barrot driver is no longer available to Windows. If you replug the BT60, Windows will see no matching driver and fall back to the generic BTHUSB via the USB\Class_E0&SubClass_01&Prot_01 compatible ID. This is what we want.

Phase 8: Force re-bind without replug

bt60_force_bind.ps1 — try BTHUSB without physical replug

If you can't or don't want to replug the BT60, this script tries pnputil /scan-devices, pnputil /remove-device, and pnputil /enable-device in various combinations to get Windows to re-evaluate the driver.

This works sometimes but not always. The most reliable fix is a physical replug.

Phase 9: Make BT60 the primary radio

bt60_make_primary.ps1 — disable competing radios

The second root cause: Windows allows only one active Bluetooth radio. If AR3012 is already active, BTHUSB refuses to start for the BT60 and logs event ID 6.

This script:

  1. Disables AR3012 (pnputil /disable-device).
  2. Tries to disable QCA61x4 (this often fails because the QCA61x4 device is in a phantom state, but that's fine).
  3. Removes the Barrot device instance and triggers a rescan.
  4. Waits for the BT60 to re-enumerate.

After this, the BT60 should be the only active Bluetooth radio.

Phase 10: Permanent lockdown

bt60_permanent_v2.ps1 — make it permanent

This is the script you want to keep. It does everything from phases 6, 7, 9, and additionally:

  1. Hard-pins the BT60 device's Service=BTHUSB in the registry so it can never be overridden.
  2. Re-sets the device's HardwareID and CompatibleIDs to the standard Bluetooth HCI USB class. This is the registry-level equivalent of "this is a Bluetooth device."
  3. Overrides the device's DeviceClass GUID and DeviceType in Device Parameters. This is a belt-and-suspenders measure — even if the compatible IDs change, the device is forced to be a Bluetooth radio.
  4. Adds brbtusb.inf and brtlinkusb.inf to SearchDisallowedDrivers policy. Windows will refuse to install these drivers.
  5. Marks the cached oem*.inf packages in DriverDatabase as Deny=1. Even if you manually try to install them, Windows will refuse.
  6. Marks all historical instances of AR3012 and QCA61x4 with ConfigFlags=1 (disabled) in the registry. This survives device replug.
  7. Creates a scheduled task BT60 Lockdown that re-runs steps 1-6 at every boot and logon. The script lives at C:\Windows\System32\BT60_Lockdown.ps1.
  8. Restarts the BT60 device to apply all the changes.

After this, your BT60 is permanently bound to BTHUSB, the Barrot driver can never come back, and the competing radios are disabled at every boot.

Phase 11: Audio profile investigation (optional)

bt60_audio.ps1 — investigate Bluetooth audio profile

This is a separate concern: if you're using Bluetooth headphones (we used a Joyroom JR-X2 in the original session), Windows creates two audio devices for the same headphones:

  • Headphones (JR-X2 Stereo) — A2DP profile, stereo, high quality
  • Headset (JR-X2 Hands-Free AG Audio) — HFP profile, mono, low quality

Windows may switch between them automatically depending on what an app requests. To force stereo only:

Quick fix: Right-click speaker icon → Sound settings → select "JR-X2 Stereo" as the default output. Also click it and set as the "default communication device."

Permanent fix: services.msc → "Bluetooth Handsfree Service" → Startup type: Disabled. After re-pairing, the headphones will only use the A2DP stereo profile. Your laptop's built-in microphone will be used for any mic needs.

End of guide

For the no-fluff version, see QUICKSTART.md. For the technical deep-dive with all registry paths and event IDs, see bt60_incident_report.md.