Raspberry Pi Pico (RP2040) Will not upload when using my windows pc (all other boards work)

So for some context I have been able to upload a simple blink program to the board from my mac as a test to see if the board was the problem. The upload worked without a hitch which leads me to believe it has to do with the environment and not PIO or the board. Has anyone else experienced this error. There is no obvious fault here in the output just that it always fails right after compiling. If I drag the resulting uf2 file into the pico it works as expected. Not sure how I should go about this…
System Specs:
Windows 11
Newest Version of VSCode (new computer everything is completely up to date)
Raspberry Pi Pico
Here is the output:

Processing pico (platform: raspberrypi; board: pico; framework: arduino)
------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/raspberrypi/pico.html
PLATFORM: Raspberry Pi RP2040 (1.7.0) > Raspberry Pi Pico
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, raspberrypi-swd)
PACKAGES: 
 - framework-arduino-mbed @ 3.1.1 
 - tool-openocd-raspberrypi @ 2.1100.0 (11.0) 
 - tool-rp2040tools @ 1.0.2 
 - toolchain-gccarmnoneeabi @ 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 37 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio\build\pico\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  15.1% (used 40696 bytes from 270336 bytes)
Flash: [          ]   0.2% (used 4034 bytes from 2097152 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
Looking for upload port...
Auto-detected: COM3
Forcing reset using 1200bps open/close on port COM3
Uploading .pio\build\pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1
====================================================== [FAILED] Took 15.23 seconds ======================================================

 *  The terminal process "C:\Users\bickf\.platformio\penv\Scripts\platformio.exe 'run', '--target', 'upload'" terminated with exit code: 1. 

As discussed in https://github.com/platformio/platform-raspberrypi/issues/2#issuecomment-828586398, on Windows you are required to use https://zadig.akeo.ie/ to load the right driver for when the Pico is in bootloader mode.

I have downloaded the drivers and still no luck even with full reboot of system. The device now doesn’t show up in my device manager at all for any sort of debugging

Please plug in the Pico in bootloader mode (hold down BOOTSEL and keep it pressed while inserting the USB cable) and show a screenshot of devices in Zadig with Options → List all Devices turned on.

Example

grafik

Update I was able to pull it back up and re-do the drivers but it still doesn’t pop up on any communication port. Everything still works fine for all arduinos as well

I have a slightly similar situation. I uploaded the firmware via Arduino IDE and then via PlatformIO. Then my rp2040 com port stopped showing. I uploaded flash_nuke.uf2 to using bootsel button. Then strange device name appeared in Arduino IDE device list.I selected it and loaded my firmware.The firmware downloaded and the com port appeared in the list again. But in subsequent attempts to update the firmware. The firmware storage disk will not load, and Windows writes about an unrecognized device while rp2040 loaded with bootsel button. I tried to install the driver by selecting this device in Zadig with libusb-win32 driver, but it gave an error, pls help what to do.

If the firmware you upload crashes the board (with a e.g. HardFault), you will loose the COM port. Can you verify that the blinky firmware works fine and that the COM port stays available when you upload with PlatformIO? Of course, with a crashed board, you might need to manually copy .pio/build/pico/firmware.uf2 into the BOOTSEL USB drive once.

If Blinky code works fine, the problem is in your code instead.

Perhaps my story was written long and confusingly.But now my device shows the com port and the code that I uploaded to it is working normally (it displays images and triggers an interrupt when the button is pressed).The hard drive does not appear when I want to upload new firmware. Windows writes about an unrecognized device with yellow triangle icon. It’s the same when I connect the device with the bootsel button held down.

Please open a new topic with a screenshot of the device manager in View → “Device By Container” mode with the Pico device expanded, and a screenshot of Zadig showing all USB Interfaces created by the Pico.

It is normal for the device to not show its boot drive anymore once you upload an Arduino firmware. That only happens in BOOTSEL mode, or when explicitly programmed into the firmware. (I have not yet seen code for this that would make this possible though).

Succeeding firmware upload give a special signal to the Pico by opening its (virtual / USB ) serial port at 1200bps. This causes a code in the Arduino core to trigger and reboot the board into BOOTSEL mode, in which the bootdrive is again available. The upload script can then talk to the Pico in bootloader mode via the dedicated USB interface (for which WinUSB drivers must be loaded) or the USB drive.

I deleted all saved drivers for connected devices via Device Cleanup Tool V1.2.1
When I normally connect rp2040 (rp2-b2), windows install drivers named “pico” Version 10.0.19041.2130
In device list under the ports(com & lpt) section: it named USB serial device COM6
When I connecting it with bootcell button pressed, it’s showed in another menu:
Universal Serial Bus controllers as Unknown USB Device (Device Descriptor Request Failed).

Thanks so much for this post. The last two paragraphs of this and your previous post on this topic were the keys that solved a problem that has had me stymied for two days.