Wolverine V3 Pro always reports 10% battery to Windows APIs | Razer Insider
Skip to main content
Question

Wolverine V3 Pro always reports 10% battery to Windows APIs

  • July 30, 2026
  • 2 replies
  • 11 views
EBYRWA

Hello Razer Support,

I am reporting a repeatable battery-telemetry bug with the Razer Wolverine V3 Pro on Windows when it is connected through the 2.4 GHz wireless dongle. The controller works wirelessly, but Windows applications cannot obtain a valid battery level. A battery widget using the public Windows controller APIs always displays 10%, regardless of charging, reconnecting, or firmware updates.

SYSTEM AND DEVICE

• Controller: Razer Wolverine V3 Pro (Xbox/PC)
• USB vendor/product ID: VID 0x1532, PID 0x0A3F
• Connection under test: 2.4 GHz wireless dongle; controller is not physically connected by USB
• Operating system: Windows 11 Home 64-bit, version 10.0.26200, build 26200
• Controller firmware: 2.04.00_r1

REPRODUCTION STEPS

1. Connect the controller to Windows through its wireless dongle.
2. Disconnect the USB charging/data cable so the controller is operating wirelessly from its battery.
3. Read the controller battery through Windows.Gaming.Input.Gamepad.TryGetBatteryReport().
4. Calculate the percentage from RemainingCapacity / FullChargeCapacity.
5. Repeat after charging, unplugging, reconnecting, power-cycling the controller, and restarting the application.

ACTUAL RESULT

Windows.Gaming.Input repeatedly returns capacity information that calculates to exactly 10%. The displayed level remains 10% even after the controller has been charged and the official firmware updater reports that the controller was successfully updated.

Independent API tests show mutually inconsistent battery information for the same wireless controller:

• Windows.Gaming.Input: returns a BatteryReport that produces a fixed 10% reading.
• Microsoft GameInput: finds the controller, but reports battery status 0 / battery not present, with remaining and full capacity both zero.
• XInput before the firmware update: reported battery type 0 (disconnected/no battery data).
• XInput after firmware 2.04.00_r1: reports battery type 1 (wired) and level 3 (full), even though the controller is actually connected wirelessly through the dongle.

Because the controller continues to work while unplugged, these readings appear to be incorrect telemetry rather than an absent battery. The three supported Windows input APIs disagree, and none provides a trustworthy wireless battery percentage.

EXPECTED RESULT

When the Wolverine V3 Pro is used wirelessly, its firmware/dongle should expose the real battery charge or at least a consistent battery status through the Windows Gaming Input, GameInput, and XInput interfaces. Windows applications should not receive a permanent 10%, “no battery,” or “wired/full” state for the same wireless device.

TROUBLESHOOTING ALREADY COMPLETED

• Installed the official Razer firmware update successfully; the updater confirmed completion.
• Verified the installed controller firmware is 2.04.00_r1.
• Tested while the controller was plugged in and while it was operating wirelessly.
• Restarted and retested the battery overlay after the firmware update.
• Confirmed the problem independently with Windows.Gaming.Input, GameInput, and XInput instead of relying on one application.

REQUEST

Please escalate this to the Wolverine firmware/driver team and fix the battery-reporting implementation for VID 1532 / PID 0A3F. This prevents Windows battery widgets and other software from showing the controller’s real charge when it is used wirelessly. If a beta firmware, driver, diagnostic utility, or temporary workaround is available, please provide it.

I can provide the small diagnostic probe source code and additional API output if that would help reproduce the issue. Please let me know which logs or traces the engineering team needs.

2 Replies

EBYRWA
  • EBYRWA
  • Author
  • Insider Mini
  • July 30, 2026

Additional diagnostic findings:

I captured USB traffic from the controller in both wired and HyperSpeed wireless modes after updating to firmware 2.04.00. In both modes, the controller itself repeatedly sends this GIP Status Device packet:

03 20 <sequence> 04 80 00 00 00

According to Microsoft's GIP USB Status Device format, payload byte 0 is a bitfield. The value 0x80 reports full power, but battery type 0 and battery level 0 (critical). That malformed value explains why Windows.Gaming.Input consistently exposes 10%—the value originates in the controller, not the Windows widget.

Static analysis of the official 2.04.00 controller firmware found two Status Device constructors that generate 0x80, including a direct constant write of 0x00000080 to payload bytes 4–7. The same code is present in firmware 2.03.00.

The controller does track a real filtered 0–100 battery value internally, which is also consistent with the controller's red Razer-logo low-battery warning, but the GIP Status Device path does not use it. A correct fix appears to be to encode that internal battery state as rechargeable battery levels 0x88 through 0x8B instead of always sending 0x80.

Could Razer please forward this to the Wolverine V3 Pro firmware team and correct the GIP Status Device battery bitfield in an official firmware release? I can provide the wired and wireless USBPcap captures privately if needed.

EBYRWA
  • EBYRWA
  • Author
  • Insider Mini
  • July 30, 2026

One more reproducible finding after implementing an independent read-only probe:

Firmware 2.04.00_r1 exposes a real, changing battery measurement through a direct GIP query even though the standard Windows battery paths remain incorrect. The query is sent through IOCTL 0x40015C04. A response is accepted only when it has the verified 02 1F ... 02 07 80 signature and a valid XOR checksum. The raw battery byte converts as raw * 100 / 255.

Observed examples:
• Wireless endpoint 0x84: 130/255 = 51.0%
• Wired endpoint 0x81: 124/255 = 48.6%
• Later wireless reading: 127/255 = 49.8%

Fresh direct readings resumed correctly through wired/wireless changes, controller power cycles, sleep/resume, receiver removal/reinsertion, service restart, and Windows reboot. During the same sessions, Windows.Gaming.Input, GameInput, and XInput continued to expose the previously reported fixed 10%, no-battery, or wired/full states. The official Razer Controller Setup for Xbox app also showed a meaningful battery category (“Med”).

This isolates the defect to the standard battery-reporting path: the controller already knows its charge, but its normal GIP Status Device message does not publish that state correctly. An official firmware fix should map the existing internal/direct-query battery value into a valid rechargeable-battery Status Device value.

I have retained the diagnostic source, checksum/framing notes, Microsoft protocol/API references, capture hashes, and focused wired/wireless USBPcap traces. I can provide those privately to Razer engineering if requested.

CookiesAccessibility statement