Win32 Disk Imager reports success, the progress bar reaches 100 percent, and then the target device does nothing, shows an error, or boots into something unexpected. That feels contradictory, but it is not: a successful write only proves the bytes were copied to the card. It does not prove the image matches the hardware, that the boot files survived intact, or that the card can reliably hold what was written. Diagnosis therefore means separating the write from the boot — the copy can be perfect and the boot can still fail for a completely different reason.
Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only) copies the whole device sector by sector and does not parse filesystems — it does not check whether an image is bootable, whether it is for your device, or whether the card is genuine. It also does not parse ISO filesystems, so an ISO written as if it were a raw image will not behave like a proper disk image. If you wrote an ISO file directly, or an image built for different hardware, the write can succeed and the device still cannot boot, because the bytes on the card do not form a bootable layout for that device.
Likely causes, in order of probability
- Wrong image for the hardware. An image for a different board revision, model, or device will not boot even if the write is flawless. Board revisions matter: check the exact model the image was built for.
- Wrong file type. An ISO, a compressed archive, or a partial download written as a raw image will not boot. Extract archives first and confirm you have a genuine .img file of the expected size.
- Corrupt or incomplete image. A download interrupted part-way, or a truncated file, can still write without error and then fail at boot when the missing or damaged sectors are reached.
- Failing or fake card. A card that accepts a write but cannot reliably read back what was written will boot intermittently or not at all. See how to test a fake card.
- Card not fully seated or wrong slot. Some devices are picky about which slot boots, and a card that is slightly loose may be detected for flashing but not for booting.
- Power or hardware fault on the target. An underpowered supply, a failing board, or a damaged slot can mimic a bad flash.
Fixes, cheapest and quickest first
- Verify the image matches the hardware exactly. Re-read the image source: model, revision, and any notes about required card size. If there is any doubt, get the correct image before re-flashing.
- Check the image file size and, where published, its hash. A file far smaller than expected is truncated. Where the source publishes a hash, compare it; a mismatch means re-download, not re-flash. The installer hashes verified for this site’s download are the installer MD5 be92e76baabc97b3f093ff734dd3f75b and SHA-256 a51c9fc75c9caa44df03502838f229a70d484963f54675c241799093a59d8874 — those verify the installer, not your OS image, so do not confuse the two.
- Extract before writing. If the download is a .zip, .gz, or .xz archive, extract it fully first and write the extracted .img. Writing the archive itself is a common silent failure.
- Re-flash to a different, known-good card. Use a card from a reputable source, preferably one that has booted a device before. If the new card boots, the old card was the problem.
- Use Verify Only after writing. Win32 Disk Imager’s Verify function re-reads the card and compares it with the image. A verify failure means the card did not retain the write, even though the write reported success — see verify only.
- Check power and seating on the target. Reseat the card firmly, use the recommended power supply for the device, and try the device’s other slot if it has one.
For Raspberry Pi specifically, also check the Pi won’t boot after flashing guide and SD card shows smaller after flashing, since Pi images have their own partition and expansion quirks. A fresh copy of the tool is on the download page, and the troubleshooting hub collects the other post-write symptoms.
When to stop and switch tools
Stop re-flashing the same image to the same card if verify fails repeatedly, if the same image boots from a different card, or if a known-good image also fails on the target device. The first case means the card is unreliable and should be replaced. The second case means the image or the hardware match is wrong, and another imager writing the same bytes will produce the same non-booting card. The third case points at the target device or its power supply, not at the flashing tool. Switching imagers is a useful diagnostic when you suspect the write itself, but it cannot fix a wrong image, a fake card, or a faulty board.
FAQ
The write said success, so why will the device not boot?
Because a successful write only means the bytes were copied. The device may still fail to boot if the image is for different hardware, the boot partition is damaged, or the card is unreliable.
Should I re-flash the same image again?
Only after checking the likely cause. Re-flashing the same image to the same failing card usually reproduces the same result; verify the image, the target hardware, and the card first.
How do I know whether the card or the image is at fault?
Test one variable at a time: the same image on a different card, and a known-good image on the same card. Whichever swap fixes booting identifies the faulty side.