Wednesday, August 19, 2026 76°F Knoxville
Mon–Fri 9–5 ET Answered by a human
Book a call →
Infrastructure · RESOLVED

Lenovo ThinkBook Camera Stuck in DFU Mode After Update

A Camera DFU Device in Device Manager means the webcam is stuck in firmware update mode, usually after a Windows update. Here is the remote fix.

Corey Watson · Managing Member, Limehawk •Updated Jan 2025•8 min
DFUFIXEDCASE REPORT
under 10 minutes
Resolution time

What is a Camera DFU Device?

A Camera DFU Device is not a missing driver. DFU means Device Firmware Update: the webcam microcontroller is sitting in bootloader mode, usually because a Windows update interrupted a firmware flash. Device Manager lists it as a generic WinUsb device instead of a camera. Until something pushes firmware or tells it to leave DFU, Teams and the Camera app will keep saying they cannot find the camera.

Incident

A client’s Lenovo ThinkBook 16 G6 ABP (Ryzen 7 7730U, Windows 11 24H2) had 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.” The user was overseas (about 20,000 miles away), so this had to be fixed in place over a remote session — no desk-side visit, 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:

code 
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:

code 
# 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:

code 
# 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

A dead camera 20,000 miles from the office is just another ticket when the machine is already on the help desk we run. Distance stops mattering once the tooling is in place.

Key takeaways