Title
picotool info crashes with access violation (0xC0000005) on Windows in 2.3.0, works fine in 2.2.0-a4
Body
Description
picotool info (any variant — no flags, -b, -a, filtered by --vid/--pid, with --rp2040) crashes immediately with a Windows access violation (STATUS_ACCESS_VIOLATION, 0xC0000005) when run against a real RP2040 device in BOOTSEL mode. No output is printed before the crash.
picotool reboot against the same device works correctly (no crash), so basic USB connectivity to the device is fine — it's specifically info that fails.
Environment
OS: Windows 11 Home, build 10.0.26200
picotool: v2.3.0 (Windows, GNU-16.1.0, Release) — installed via the official Raspberry Pi Pico VS Code extension (pico-sdk manager), binary also reproduced from the raspberrypi/pico-sdk-tools release v2.3.0-0 asset picotool-2.3.0-x64-win.zip
Device: RP2040 rev B2, 2MB flash, in BOOTSEL mode (USB VID:PID 2E8A:0003), flashed with blink_universal from pico-examples (built with SDK 2.3.0)
USB driver: WinUSB bound via Zadig to the correct composite interface (RP2 Boot, Interface 1 / the PICOBOOT vendor interface — verified via Win32_PnPSignedDriver, driver provider libwdi, oem*.inf). Interface 0 (mass storage / RPI-RP2 drive) remains on the stock Microsoft usbstor.inf driver, untouched.
Steps to reproduce
Put an RP2040 board into BOOTSEL mode.
Confirm WinUSB is bound to the device's vendor interface (e.g. via Zadig).
Run any of:
picotool info
picotool info -b
picotool info -a
picotool info --rp2040
picotool info --vid 0x2e8a --pid 0x0003
Expected behavior
Program/device/build information is printed, as it is on picotool 2.2.0-a4 against the identical device/machine:
Program Information
name: blink_universal
web site: https://github.com/raspberrypi/pico-examples/tree/HEAD/universal/blink_universal
binary start: 0x10000000
binary end: 0x10040494
...
Device Information
type: RP2040
revision: B2
flash size: 2048K
flash id: 0xE660D05113712630
Actual behavior
The process crashes silently (no stdout/stderr output) with exit code -1073741819 (0xC0000005). Windows Event Viewer (Application log, source Application Error) confirms the fault is inside picotool.exe itself (not ntdll or a system DLL), at a consistent, deterministic offset across repeated runs:
Faulting application name: picotool.exe, version: 0.0.0.0, time stamp: 0x6a47e18e
Faulting module name: picotool.exe, version: 0.0.0.0, time stamp: 0x6a47e18e
Exception code: 0xc0000005
Fault offset: 0x000000000002e3c7
Isolation / things ruled out
Not a libusb DLL issue: picotool.exe is statically linked against libusb (confirmed by deleting libusb-1.0.dll from the install directory entirely — identical crash occurs, so the DLL was never even being loaded).
Not a WinUSB/driver binding issue: confirmed correct interface has WinUSB bound (see Environment above); other interface untouched.
Not device/firmware-specific: reproduces regardless of info flags used, and regardless of which BOOTSEL-mode RP2040 device is targeted.
Is a regression specific to 2.3.0: downloaded picotool-2.2.0-a4-x64-win.zip from raspberrypi/pico-sdk-tools release v2.2.0-4 (same GNU-16.1.0 Windows toolchain, same machine, same device, same USB port/driver state) and picotool info -a works perfectly, producing the full expected output shown above. Only 2.3.0 crashes.
Additional notes
Since 2.2.0-a4 and 2.3.0 share the same compiler/toolchain and were tested on the same machine/device back-to-back, this points to a code change between 2.2.0 and 2.3.0 (rather than a toolchain or environment issue) that breaks reading device info back from an RP2040 over the PICOBOOT USB interface on Windows.
Title
picotool info crashes with access violation (0xC0000005) on Windows in 2.3.0, works fine in 2.2.0-a4
Body
Description
picotool info (any variant — no flags, -b, -a, filtered by --vid/--pid, with --rp2040) crashes immediately with a Windows access violation (STATUS_ACCESS_VIOLATION, 0xC0000005) when run against a real RP2040 device in BOOTSEL mode. No output is printed before the crash.
picotool reboot against the same device works correctly (no crash), so basic USB connectivity to the device is fine — it's specifically info that fails.
Environment
OS: Windows 11 Home, build 10.0.26200
picotool: v2.3.0 (Windows, GNU-16.1.0, Release) — installed via the official Raspberry Pi Pico VS Code extension (pico-sdk manager), binary also reproduced from the raspberrypi/pico-sdk-tools release v2.3.0-0 asset picotool-2.3.0-x64-win.zip
Device: RP2040 rev B2, 2MB flash, in BOOTSEL mode (USB VID:PID 2E8A:0003), flashed with blink_universal from pico-examples (built with SDK 2.3.0)
USB driver: WinUSB bound via Zadig to the correct composite interface (RP2 Boot, Interface 1 / the PICOBOOT vendor interface — verified via Win32_PnPSignedDriver, driver provider libwdi, oem*.inf). Interface 0 (mass storage / RPI-RP2 drive) remains on the stock Microsoft usbstor.inf driver, untouched.
Steps to reproduce
Put an RP2040 board into BOOTSEL mode.
Confirm WinUSB is bound to the device's vendor interface (e.g. via Zadig).
Run any of:
picotool info
picotool info -b
picotool info -a
picotool info --rp2040
picotool info --vid 0x2e8a --pid 0x0003
Expected behavior
Program/device/build information is printed, as it is on picotool 2.2.0-a4 against the identical device/machine:
Program Information
name: blink_universal
web site: https://github.com/raspberrypi/pico-examples/tree/HEAD/universal/blink_universal
binary start: 0x10000000
binary end: 0x10040494
...
Device Information
type: RP2040
revision: B2
flash size: 2048K
flash id: 0xE660D05113712630
Actual behavior
The process crashes silently (no stdout/stderr output) with exit code -1073741819 (0xC0000005). Windows Event Viewer (Application log, source Application Error) confirms the fault is inside picotool.exe itself (not ntdll or a system DLL), at a consistent, deterministic offset across repeated runs:
Faulting application name: picotool.exe, version: 0.0.0.0, time stamp: 0x6a47e18e
Faulting module name: picotool.exe, version: 0.0.0.0, time stamp: 0x6a47e18e
Exception code: 0xc0000005
Fault offset: 0x000000000002e3c7
Isolation / things ruled out
Not a libusb DLL issue: picotool.exe is statically linked against libusb (confirmed by deleting libusb-1.0.dll from the install directory entirely — identical crash occurs, so the DLL was never even being loaded).
Not a WinUSB/driver binding issue: confirmed correct interface has WinUSB bound (see Environment above); other interface untouched.
Not device/firmware-specific: reproduces regardless of info flags used, and regardless of which BOOTSEL-mode RP2040 device is targeted.
Is a regression specific to 2.3.0: downloaded picotool-2.2.0-a4-x64-win.zip from raspberrypi/pico-sdk-tools release v2.2.0-4 (same GNU-16.1.0 Windows toolchain, same machine, same device, same USB port/driver state) and picotool info -a works perfectly, producing the full expected output shown above. Only 2.3.0 crashes.
Additional notes
Since 2.2.0-a4 and 2.3.0 share the same compiler/toolchain and were tested on the same machine/device back-to-back, this points to a code change between 2.2.0 and 2.3.0 (rather than a toolchain or environment issue) that breaks reading device info back from an RP2040 over the PICOBOOT USB interface on Windows.