Quest Pro Controller Pairing(Soft Brick) due to Meta Server Provisioning Block & Missing Driver
I am experiencing a severe issue where my Right Quest Pro Controller completely refuses to pair. Through various troubleshooting methods, I managed to bypass the initial 5-digit code screen and successfully connected the headset to the Meta Horizon app. However, the controller pairing still fails. There is absolutely zero physical damage to the controller or headset. This happened after an official firmware update bug.
Here are the detailed symptoms and the exhaustive list of troubleshooting steps I have already performed:
1. The Symptoms
The controller LED endlessly loops: White (standby) → Blue → Green → Blue.
When attempting a firmware update, it flashes Purple/White but abruptly crashes and returns to White. Hardware vibration works, indicating a software-level block.
2. Basic & Hardware Resets (Failed)
App pairing results in a Timeout error. Manual pairing (Meta + B) vibrates but fails to connect.
15-second hard reset (until Amber light) & 60-second button hold for capacitor drain: Both failed.
Controller Factory Reset (A+Meta / X+Menu): Successfully triggered the Red/White alternating LED, but pairing still fails afterward.
3. Network & Environment Isolation (Failed)
Forced a 2.4GHz mobile hotspot connection and turned off the 5GHz router to prevent internal Wi-Fi interference.
Covered the proximity sensor with tape to prevent the headset from sleeping during the update phase.
4. App & ADB Debugging (Critical Local Findings)
Unpaired from the smartphone's Bluetooth list and completely cleared the Meta Horizon app cache/data.
Headset Factory Reset: Performed multiple times via the Android Recovery Menu.
I ran the adb shell dumpsys bluetooth_manager command. The controller's MAC address is entirely missing from the headset's bonded devices list.
Attempted adb shell pm clear com.oculus.controllerpairing and adb shell setprop persist.bluetooth.btsnoopenable true, but encountered permission/SecurityException errors.
5. Recent Logcat Updates (Fatal Meta Backend Provisioning Bug Found)
I recently investigated the live device logs via Meta Quest Developer Hub (MQDH) after a fresh reboot, and I found an absolute smoking gun proving this is 100% a Meta-side infrastructure/server defect:
E Volley : Unexpected response code 400 for [https://graph.facebook-hardware.com:443/remote_provisioning_register](https://graph.facebook-hardware.com:443/remote_provisioning_register)
E RestWrapper : (Subcode 3638006) Unauthenticated remote provisioning request
E VrAccountManagerImpl: onError called. code = 3, message = horizonos.supplement.deviceaccess.exceptions.BackendException
W OVRLibrary : null cursor received for query content://com.oculus.ocms.library/apps/com.oculus.systemdriver
W artd : Failed to determine oat file name for dex location /apex/com.meta.xr/priv-app/VrDriver/VrDriver.apk: Dalvik cache directory does not exist
Conclusion:
This log explicitly proves that after the factory reset, Meta's hardware provisioning server is actively rejecting the headset's authentication request (Unauthenticated remote provisioning request). Because of this server-side block, the headset cannot initialize or fetch the core hardware driver (com.oculus.systemdriver returns a null cursor), completely breaking the OpenXR controller session.
I am posting this here because the automated support website blocks my serial number ("Device not supported" error). Can a Meta Support agent on this forum please reach out via DM to bypass the broken automated system and manually initiate an RMA process?