Lenovo ThinkBook Camera Stuck in DFU Mode After Update

LIMEHAWK - Managed IT

Home>Incident Reports>Lenovo ThinkBook Camera Stuck in DFU Mode After Update

Resolution time

under 10 minutes

Incident

A Lenovo ThinkBook 16 G6 ABP (Ryzen 7 7730U, Windows 11 24H2) came in with a dead integrated camera after a Windows update. Teams couldn't find it, the Camera app showed "We can't find your camera," and Device Manager listed it under "Universal Serial Bus devices" as a generic "WinUsb Device" instead of under "Cameras." User was overseas — about 20,000 miles from where we are — so shipping the laptop back wasn't an option. No physical access, no vendor firmware file, no manufacturer RMA.

Symptoms

Device Manager told most of the story:

- listed under "USB devices", not "Cameras"
- shows up as "WinUsb Device"
- Hardware ID: USB\VID_1BCF&PID_0B1D (SunplusIT camera module)
- driver: generic Windows USB driver, not the camera driver

The camera's firmware hadn't been uninstalled and the hardware hadn't died. Something interrupted a firmware update during the Windows update process and the camera's controller was sitting in DFU (Device Firmware Update) bootloader mode, waiting for a firmware blob to be pushed to it. Until something either pushes new firmware or tells it to stop waiting, it will never enumerate as a camera again.

Diagnostics

Confirmed the state with PowerShell:

Get-PnpDevice | Where {$_.FriendlyName -like "*cam*"} |
  Select Status, Class, FriendlyName, InstanceId

Class came back as USB instead of Camera. That's the tell — Windows has correctly enumerated the device but it's identifying itself as a DFU bootloader, not a camera. The USB descriptor fields match what you'd expect:

- USB Class: 0xFE (Application Specific)
- SubClass: 0x01 (Device Firmware Update)
- Protocol: 0x02

Tools required

- dfu-util 0.11 Windows binaries from SourceForge — https://dfu-util.sourceforge.net/
- 7-Zip to extract the .tar.xz release archive
- Zadig (zadig.akeo.ie) as a fallback for driver reassignment if dfu-util can't see the device

dfu-util is an open-source DFU implementation. Nothing proprietary, no manufacturer firmware file. The whole binary is around 500KB.

Recovery procedure

After extracting dfu-util and dropping into its win64 directory, the sequence is:

# Navigate to dfu-util
cd "Downloads\dfu-util-0.11-binaries\win64"

# Verify working
.\dfu-util.exe --version

# List devices in DFU mode
.\dfu-util.exe -l

# Send exit command (primary method)
.\dfu-util.exe -d 1bcf:0b1d -e

# Alternate: exit with leave command
.\dfu-util.exe -d 1bcf:0b1d -s :leave

Expected behavior: the WinUsb Device disappears from Device Manager for a few seconds as the controller reboots out of bootloader and back into its normal firmware, then reappears — this time as "Integrated Camera" under the Cameras section. The Windows Camera app sees it immediately.

If dfu-util can't detect the device

Sometimes Windows has the WinUSB driver bound in a way that dfu-util can't talk to. Zadig fixes this:

1. Download and run Zadig (zadig.akeo.ie)
2. Options > List All Devices
3. Find the SunplusIT camera in the dropdown
4. Select libusbK or libusb-win32 as the target driver
5. Click "Replace Driver"
6. Retry dfu-util.exe -l and confirm it now sees the device
7. Run the exit command

Post-recovery

Reset the Windows Camera app and force a device rescan so any UWP app that cached "no camera" clears out:

# Reset Windows Camera app
Get-AppxPackage Microsoft.WindowsCamera |
  Reset-AppxPackage

# Force hardware rescan
pnputil /scan-devices

If something really stubborn is still broken, the nuclear option is pnputil /remove-device "USB\VID_1BCF&PID_0B1D\01.00.00" /subtree /force followed by /scan-devices, which forces Windows to rediscover the camera from scratch.

Why this works

DFU is a standardized USB protocol defined in the USB spec — it's not a SunplusIT thing or a Lenovo thing. When a USB device enters DFU mode, its bootloader is running in place of the normal firmware, and the bootloader exposes a standard command set:

- upload new firmware
- download current firmware
- exit bootloader and boot the existing firmware

Half the internet assumes "stuck in DFU" means "firmware is corrupted, you need a firmware file." That's not what was happening here. The firmware was intact; the bootloader just never got told to hand control over to it, because whatever update flow Windows kicked off got interrupted before it finished. The -e flag in dfu-util sends "exit/detach" — "stop waiting, boot what you already have."

No firmware files needed. No proprietary tools. No Lenovo support case. Just a standard USB DFU command that works on any DFU-compliant device.

Outcome

Ran over a remote session, total time from touching the keyboard to the Camera app showing a live feed was well under 10 minutes. No physical access, no firmware file, no manufacturer support, no replacement hardware.

- hardware: Lenovo ThinkBook 16 G6 ABP (Ryzen 7 7730U)
- camera: SunplusIT (VID 1BCF, PID 0B1D)
- OS: Windows 11 24H2
- resolution time: under 10 minutes
- physical access: not required
- manufacturer support: not required

Key takeaways

Takeaway

understanding standard protocols (USB DFU) gets you vendor-independent fixes.

Takeaway

"firmware stuck in bootloader" is not the same as "firmware is corrupt".

Takeaway

remote hardware troubleshooting is absolutely doable with the right tools and USB-level access via a remote session.

Takeaway

open-source utilities routinely out-perform the vendor's own tooling, when the vendor even has tooling.

Need help with something like this? Contact us

• Mac Running Slow: Disk Errors Causing Performance Issues (Hardware)