Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only) does not ask for confirmation per file, does not write only to a partition, and does not keep the old contents anywhere. It writes the image to the raw device. If the image is, for example, 4 GB and the wrong drive is 500 GB, the first 4 GB of that drive are overwritten with image data, and the remaining space may still contain old data that recovery tools could in principle retrieve. If the image is as large as or larger than the wrong drive, effectively the whole drive is overwritten and there is nothing left to recover from that drive itself. Either way, the overwritten sectors are gone — that is a property of magnetic and flash storage, not a limitation of a particular recovery program.

What to do immediately

• Stop using the drive now. Do not boot from it, do not save files to it, do not run a disk check that writes, and do not install recovery software onto it. Install any recovery tool on a different drive and work from there.
• Do not write anything else to it, including a new image. Every additional write overwrites more surviving sectors.
• Make a sector-level copy if you can, and recover from the copy. If the drive is still readable, image the whole drive to a different, larger drive first, then run recovery against the copy. That way a failed recovery attempt does not destroy the original further.
• Check your backups before paying for recovery. Cloud backups, an earlier Win32 Disk Imager Read image, or a copy on another drive may already hold what you need. See how to back up an SD card to an image for the backup habit that prevents this situation.

What can and cannot be recovered — honestly

• Cannot be recovered: any file, or part of a file, that lay in sectors overwritten by the image. No consumer or professional tool can read data that has been physically overwritten. Claims to the contrary are false.
• May be recoverable: files that lay entirely beyond the image’s size on a larger drive, and whose directory entries or file signatures recovery software can still find in the surviving area. Success here is partial and uncertain, not guaranteed.
• May be recoverable from elsewhere: copies in backups, email attachments, cloud storage, or other devices. These are often the real recovery path, and they are worth checking exhaustively before spending money.
• Professional recovery: a lab cannot recover overwritten sectors either. It can help with physically failing drives or complex filesystem damage in the surviving area, but it cannot reverse an overwrite. Do not pay a lab that promises otherwise.

How to prevent this next time

• Verify the drive letter and size every single time. Before clicking Write, compare the letter and the size shown in Win32 Disk Imager with the card you intend to write. If the size does not match your card, stop.
• Disconnect drives you do not intend to write. Unplug external drives and remove other cards before flashing, so the wrong drive is not even listed.
• Label your cards and readers. A card that looks identical to another is an easy mistake. Physical labels and a consistent slot reduce the risk.
• Back up before you flash anything else. A full-device Read image taken before a risky operation is the only safety net that actually works after an overwrite. See verify only and Error 5 for related safe-workflow habits.

If you need a fresh copy of the tool, use the download page, and the troubleshooting hub collects the other guides in this series. The lesson of this post is not a trick: it is a workflow change. Check letter and size, disconnect what you do not mean to write, and back up first — because after a wrong-drive write, there is no undo button, only damage limitation.

When to stop and switch tools

Stop running recovery scans if multiple tools, working from a sector copy, find nothing in the surviving area, or if the image was as large as the drive. At that point further scanning will not create data that was overwritten, and continuing to power a failing drive can do more harm. The honest stopping point is when you have checked backups, scanned the surviving area from a copy, and confirmed that the overwritten portion is unrecoverable. Switch your effort from recovery to rebuilding: reinstall, restore from backup, and change the workflow so the next flash cannot repeat the mistake.

FAQ

I just wrote to the wrong drive. Can recovery software get my files back?

For sectors that were overwritten by the image, no. Win32 Disk Imager writes the whole destination, and overwritten sectors cannot be recovered by recovery tools. Files in areas beyond the image size may still be recoverable, but anything under the image is gone.

Should I keep using the drive while I decide?

No. Stop using it immediately. Every new write risks overwriting surviving areas that recovery might still have retrieved.

Does this mean all my data is lost?

Not necessarily all of it, but you must assume the overwritten portion is lost. What survives depends on how large the image was compared with the drive, and on whether you stop writing at once.

Win32 Disk Imager makes fake cards especially painful, because a Write overwrites the entire destination and a Read copies the whole device sector by sector. A fake card may appear to accept a full-device write, then fail to boot or lose data when the device tries to read back sectors that were never really stored. If you have had a write succeed and then a boot fail, or a backup that restores with corruption, test the card before blaming the image — see write succeeded but won’t boot and slow write speed, both of which share fake cards as a common cause.

How to test with h2testw on Windows

• Back up anything on the card first, if it is still readable. The test overwrites the whole card, so anything on it will be destroyed. Copy what you can before testing.
• Download h2testw from a reputable source and run it as administrator. Select the card’s drive letter carefully — writing test data to the wrong drive destroys that drive’s contents, just as a Win32 Disk Imager write would.
• Choose Write + Verify and test the full capacity, not a small sample. A partial test can miss a fake card whose real capacity is larger than the sample but smaller than printed. Only a full test is conclusive.
• Wait for the result. A genuine card completes with no errors and reports the full tested capacity. A fake card reports data loss, verification errors, or a real capacity far below printed — for example, a card sold as 128 GB that only holds 16 GB.
• Do not trust a card that fails, even partially. If the test shows any significant shortfall, the card is not usable for reliable storage, even for files smaller than its real capacity, because its controller is already lying about its geometry.

F3 on Linux and macOS

F3, short for Fight Flash Fraud, provides the same idea on Linux and macOS: f3write fills the card, f3read verifies it, and the report shows real versus claimed capacity. If you work across systems, F3 is the cross-platform counterpart to h2testw. The principle is identical — write everything, read everything back, believe only the verified result — and a quick format or a capacity reading in a file manager proves nothing on its own, because the fake controller reports the fake size to the operating system too.

What to do with the result

• Pass: the card is genuine as far as a full test can prove. It can still wear out or fail later, so keep backups, but capacity fraud is ruled out.
• Fail: stop using the card for anything important, return it if you can, and replace it from a reputable seller. Do not keep it as a spare for small files; its controller cannot be trusted.
• Uncertain or interrupted: if the test was interrupted by a reader disconnect, retry with a different reader and a direct port before concluding. A reader fault can mimic a card fault — see Error 121.

When you replace a failed card, buy on sustained reliability, not the cheapest price per gigabyte. A durable endurance microSD card (Sponsored) and a reliable USB card reader (Sponsored) remove the two hardware variables that most often confuse fake-card diagnosis: a slow or flaky reader can make even a genuine card look bad. A fresh copy of Win32 Disk Imager is on the download page, and the troubleshooting hub covers the symptoms that lead people to test in the first place.

When to stop and switch tools

Stop testing a card that has failed a full h2testw or F3 test on two readers. No second test, no format, and no different imaging tool will make its missing capacity appear, because the capacity was never there. Switching tools is useful only when a test was interrupted by hardware — a disconnect or a reader fault — and you need a clean rerun. Once a full, uninterrupted test has failed, the verdict is final: replace the card.

FAQ

What is h2testw and what does it do?

h2testw writes test data to the whole card and reads it back, verifying that the card really holds as much as it claims. It is a free Windows tool widely used to expose fake-capacity cards.

How long does a full test take?

It depends on card size and speed. A large card on a slow reader can take hours, because the test must write and read every sector to be conclusive. A quick partial test cannot prove a card is genuine.

Can a fake card be fixed by formatting?

No. Formatting cannot create capacity that is not physically there. A card that fails a full test should be replaced, not reformatted and trusted.

Is F3 an alternative if I also use Linux or Mac?

Yes. F3 provides similar write-and-verify testing on Linux and macOS, while h2testw is the usual Windows choice. Win32 Disk Imager itself is Windows-only, so h2testw fits the same PC workflow.

Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only) does not compress, cache, or otherwise accelerate the copy; it writes sectors in order until the device is done. That means a 64 GB card will always take substantially longer than a 16 GB card on the same hardware, and a card that is nearly worn out will write far slower than a new one of the same rating. Headline speed ratings on packaging describe ideal sequential reads, not sustained full-device writes, so a card that benchmarks well for a few seconds can still slow dramatically over a full write as it heats up or hits worn flash.

Common causes

• Slow or old reader. A USB 2.0 reader, or a cheap USB 3.0 reader with a poor controller, caps the transfer well below what the card can do.
• Hub, front port, or long cable. Hubs and poor connections can negotiate down to USB 2.0 speeds or introduce retries that look like slowness.
• Card itself is slow or worn. Low-grade cards, heavily used cards, and fake cards with slow flash all write slowly across their whole capacity.
• PC load or power saving. Another heavy disk task, antivirus scanning the removable drive, or USB power management throttling the port can all slow a write.
• Nearly full or fragmented target. This matters less for raw writes than for file copies, but a card with many bad or worn sectors will retry and slow down.

Fixes, cheapest and quickest first

• Close other disk activity and antivirus scans of the removable drive. Pause a backup, a scan, or a large copy running at the same time, then retry.
• Move to a direct USB 3.0 port. Plug the reader directly into the PC, not a hub, and try a rear port on a desktop. If Windows reports the device as USB 2.0, the port or cable is the limiter.
• Try a different reader. This is the single most revealing test. If the same card writes dramatically faster in another reader, replace the reader — it was the bottleneck.
• Test a different, known-good card. If every card is slow in every reader on that PC, suspect the PC’s USB subsystem or drivers. If only one card is slow everywhere, that card is worn, low-grade, or fake — see how to test a fake card.
• Disable USB selective suspend for the write. In Power Options, turn off USB selective suspend so the port is not throttled mid-write.
• Update USB controller drivers from the PC maker. Use the maker’s driver page and reboot before retesting.

When the reader is the bottleneck, replacing it is a genuine fix, not an upgrade for its own sake. A reliable USB 3.0 SD card reader (Sponsored) removes the most common cap, and if the card itself is the limiter, a durable endurance microSD card (Sponsored) is built for sustained writes rather than burst headline speeds. Choose on sustained-write suitability and capacity you actually need, not on the largest speed number on the box. Neighbouring timeout symptoms are covered in Error 121, and a fresh copy is on the download page; the troubleshooting hub collects the rest.

When to stop and switch tools

Stop optimising Win32 Disk Imager if a different reader, a direct USB 3.0 port, a known-good card, and updated drivers all still produce the same slow write on that PC, while the same card and reader are fast on another PC. The limiter is then the PC’s USB subsystem, and another imager copying the same sectors will hit the same limit. Conversely, if one card is slow in every reader and every PC, stop re-flashing it and replace it: a card that writes slowly everywhere is telling you its flash is worn or counterfeit, and repeated full writes will only wear it further.

FAQ

Is slow writing normal for large cards?

To a degree, yes. A full-device write copies every sector, so a large card takes a long time even on good hardware. The problem is when it is far slower than the same card and reader managed before.

Will a faster card always write faster?

Not on its own. The reader, the USB port, and the card’s sustained write performance all matter. A fast card in a slow reader is still limited by the reader.

Should I stop a very slow write part-way?

If it has truly stalled for a long time with no progress, stopping is reasonable, but expect the card to be in an incomplete state and re-flash from scratch after fixing the bottleneck.

Normally, Win32 Disk Imager’s Read copies the whole device sector by sector, and the output size equals the full device size with no compression. That is predictable: a 32 GB card produces a 32 GB image, even if only 2 GB is used. Read Only Allocated Partitions is meant to avoid that waste by reading only allocated partition areas. In practice, users have reported that it can produce an empty or tiny image, particularly when the partition table is unusual, when partitions are not recognised as allocated in the way the program expects, or when the card’s layout includes partitions Windows does not mount. These are user-reported issues, not certified bugs, and the exact trigger varies by card — which is why verification, not assumption, is the remedy.

Why the image comes out empty or tiny

• Partition table not interpreted as expected. If the program does not recognise the partitions as allocated, it may read little or nothing.
• Linux or unusual partitions. Cards with Linux partitions, multiple small partitions, or non-standard layouts are more likely to confuse the allocated-only logic than a single FAT partition.
• Card not cleanly recognised. A card that Windows sees only partially, or a reader that drops during the read, can truncate the allocated calculation.
• Wrong device selected. Reading the wrong, smaller device — for example a RAM disk or a small partition — produces a small image that looks empty compared with expectations. Always confirm the device size before reading.

Fixes, cheapest and quickest first

• Check the image size immediately after the read. Compare it with the used space on the card. If it is orders of magnitude smaller and you expected data, do not trust it — treat it as a failed backup until proven otherwise.
• Do a full-device Read instead. Uncheck Read Only Allocated Partitions and read the whole device. The file will be large — equal to the full device size — but it is the predictable, complete copy. See allocated only read and how to back up an SD card to an image.
• Compress the full image afterwards. A full image compresses well when much of the card is empty. Use 7-Zip or a similar tool on the .img file — see compress an image with 7-Zip — rather than relying on allocated-only reading to save space.
• Test-restore before you depend on any image. Write the image to a spare card and confirm the device boots or the files are present. An untested backup is not a backup.
• Re-read with a different reader if the full read also looks wrong. A flaky reader can truncate reads, so a second reader is a cheap diagnostic before blaming the option itself.

The practical rule is simple: use allocated partitions only as an experiment, never as your sole backup for irreplaceable data, until you have test-restored an allocated image from that exact card layout and confirmed it works. For anything important, the full read plus compression route is slower and larger on disk, but it removes the uncertainty. Get a fresh copy from the download page if needed, and see the troubleshooting hub for related read problems.

When to stop and switch tools

Stop using the allocated-partitions option for that card if it repeatedly produces tiny or empty images while a full read produces a correct, restorable image. That tells you the option and that card’s layout do not get along, and retrying it will not change the layout. Switch to full reads plus compression for that card. If even a full read produces a tiny or corrupt image, stop and suspect the reader or the card itself — see Error 121 for the hardware checks — because no read option can fix a device that cannot be read reliably.

FAQ

What does Read Only Allocated Partitions actually do?

It is intended to read only the parts of the device that belong to allocated partitions, rather than the whole device, so the resulting image should be smaller than a full-device copy.

Why is my allocated-partitions image tiny or empty?

User reports describe cases where the option produces a much smaller image than expected, or one that appears empty, often linked to how the program interprets the partition table on that particular card.

Should I use allocated partitions for backups I depend on?

Only after verifying the image restores correctly. For a backup you cannot afford to lose, a full-device Read that you have test-restored is the safer choice until you have proven the smaller image works.

Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only) enumerates physical and removable drives when it starts, so it can populate the device dropdown. A RAM disk driver that hooks disk enumeration, reserves a drive letter aggressively, or presents a virtual device that the program does not handle cleanly can interrupt that startup enumeration. The result is a crash before the main window is usable, which looks like a broken program but is really a conflict between two pieces of software that both want to manage drives.

Why the RAM disk conflict happens

• Drive-letter interception. Some RAM disk drivers reserve letters or remap them dynamically, confusing enumeration at startup.
• Virtual device handling. A virtual disk that does not behave exactly like a physical removable drive can trigger an unhandled path during enumeration.
• Driver load order. If the RAM disk driver loads late or reloads, the device list can change while Win32 Disk Imager is reading it.
• Coincidental causes. Not every startup crash is the RAM disk. A corrupt install, a conflicting shell extension, or a damaged .NET or Visual C++ runtime can produce similar symptoms, so the RAM disk test is diagnostic, not a verdict.

Fixes, cheapest and quickest first

• Disable the RAM disk temporarily and relaunch. Stop or disable the RAM disk in its own control panel, reboot if it requires it, then launch Win32 Disk Imager as administrator. If it now starts normally, you have confirmed the conflict.
• Change the RAM disk drive letter. Assign the RAM disk a high, unused letter far from your card readers, reboot, and test again. Letter collisions are a common trigger.
• Start Win32 Disk Imager before the RAM disk loads. If your RAM disk software allows delayed start, set it to start after login rather than at boot, launch Win32 Disk Imager first, and see whether the order matters.
• Update the RAM disk software. Check the vendor’s site for a newer version; driver fixes for enumeration conflicts do appear, and an old driver on a newer Windows build is a plausible cause.
• Reinstall Win32 Disk Imager cleanly. Uninstall it, reboot, and reinstall from the download page. If the crash persists only with the RAM disk enabled after a clean reinstall, the conflict verdict is strong.
• Test on a PC without a RAM disk. If you have a second PC, confirm the same installer and image workflow start normally there. That isolates the PC configuration from the program itself.

If you must keep the RAM disk running, the practical compromise is to disable it only for imaging sessions: disable, flash or read, then re-enable. That is inconvenient but reliable, and it avoids permanently removing software you use for other work. Record which RAM disk letter and version you used, so if the crash returns after an update you can compare.

Related startup and access problems are covered in Error 5 and the troubleshooting hub. Note that Win32 Disk Imager is Windows-only with no Mac or Linux version, so a RAM disk conflict on Windows cannot be sidestepped by switching operating systems on the same PC — the fix is on the Windows configuration.

When to stop and switch tools

Stop tweaking Win32 Disk Imager if disabling the RAM disk reliably fixes startup, but you cannot or will not disable it, and letter changes and driver updates do not help. At that point the pragmatic move is to use a different imaging tool for the session, or to do the imaging on a PC without a RAM disk, rather than spending hours hunting a driver interaction. Conversely, if the crash happens with no RAM disk installed, on a clean reinstall, and on a second PC, stop blaming the RAM disk and investigate the install, runtime libraries, or Windows installation itself.

If the program starts but then fails mid-transfer instead of crashing at launch, the cause is different: see Error 121 for USB timeouts and slow write speed for reader and port bottlenecks.

FAQ

Why would a RAM disk crash Win32 Disk Imager on startup?

User reports describe a conflict when a RAM disk driver reserves drive letters or intercepts disk access in a way that interferes with how the program enumerates devices at startup.

Can I keep my RAM disk and still use Win32 Disk Imager?

Sometimes. Disabling the RAM disk only for the imaging session, or changing its drive letter, has resolved the conflict for some users. If the crash returns, the RAM disk driver is the prime suspect.

Is the crash a sign of a corrupt Win32 Disk Imager install?

Not usually. If the program crashes before showing its window, and only on a PC with a RAM disk, the conflict explanation fits better than a corrupt install. A clean reinstall is still worth one try.

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.

Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only) lists removable drives by their Windows drive letters. If Windows has not mounted the card, there is nothing for the program to list. That is different from a write error: the program never gets a chance to open the device. Common causes are a card that is not fully seated, a reader on a hub or a failing port, a drive-letter conflict with a network drive or another device, a card whose partition table Windows cannot read, or a driver that has not loaded for the reader.

Why the drive letter is missing

• Not seated or not recognised. The card is loose in the slot, the reader is loose in the USB port, or Windows has not finished enumerating the device.
• Hub or port problem. Unpowered hubs and worn front-panel ports frequently fail to enumerate cards that work on a direct port.
• Letter conflict. Windows tried to assign a letter already used by a network mapping or a hidden device, so the card gets no letter.
• Unreadable partition table. A card with a damaged partition table, or one formatted with a layout Windows does not mount, may appear in Disk Management as a raw device with no letter.
• Driver issue. The reader’s driver failed to load, or a Windows update changed USB controller behaviour.

Fixes, cheapest and quickest first

• Reinsert cleanly and wait. Remove the card, reinsert it firmly until it clicks, and wait ten seconds for Windows to recognise it before opening Win32 Disk Imager. Run the program as administrator, as raw access requires elevation — see Error 5 if you hit an access error next.
• Move to a direct port. Take the reader off any hub and plug it into a port on the PC itself. Try a second port if the first still shows nothing.
• Open Disk Management and look for the device. Press Windows + X, choose Disk Management, and look for a removable disk of roughly the card’s size, even if it has no letter. If it is there, right-click it and choose Change Drive Letter and Paths, then Add a free letter.
• Resolve a letter conflict. If the letter you expect is taken by a network drive, assign the card a high, unused letter such as M or S in Disk Management.
• Try a different reader and a different PC. If no PC sees the card in Disk Management, suspect the reader first, then the card. If a second reader on a second PC sees it, the first reader or port was the problem.
• Reinstall the reader driver. In Device Manager, find the reader under Disk drives or USB controllers, uninstall the device, unplug it, plug it back in, and let Windows reinstall the driver.

If Disk Management shows the card as unallocated or raw and you need the data on it, do not format it yet. Formatting will destroy the existing layout. First try reading it on another PC or with a recovery-oriented read; if the data does not matter, you can initialise and format it in Disk Management and then flash normally. If you need a fresh copy of the tool, use the download page, and return to the troubleshooting hub for neighbouring symptoms such as Error 121.

When to stop and switch tools

Stop chasing a letter if the card appears in no PC, in no reader, and in neither Disk Management nor Device Manager, after trying direct ports and a driver reinstall. At that point the card or its controller is likely dead, and no imaging tool can select a device Windows cannot see. Switching tools will not help until Windows sees the hardware. If the card is seen but its partition table is damaged and the data matters, stop writing to it and use a read-only recovery approach first; writing a new image over a damaged card destroys whatever was recoverable.

FAQ

Why does the card not appear in Win32 Disk Imager at all?

Usually because Windows has not assigned it a drive letter, the reader is not recognised, or the card is not seated. Disk Management will show whether Windows sees the device at all.

Can I write to a card with no drive letter?

Win32 Disk Imager lists devices by drive letter, so a card with no letter cannot be selected. Assign a letter in Disk Management first, or fix the reader connection.

Is a missing drive letter a sign the card is dead?

Not on its own. Letters go missing for simple reasons — a hub, a driver, a letter conflict — and the card often works fine once Windows assigns a letter again.

This is a direct consequence of how Win32 Disk Imager works. It copies a whole device sector by sector, and a Read copies the full device size with no compression. An image built from, say, a 4 GB card therefore contains a 4 GB partition layout even when you write it to a 64 GB card. The extra space is not lost and not overwritten with data; it is simply not yet assigned to any partition. The same logic explains why a backup image file is as large as the whole card, not just the files on it — see allocated partitions and empty images for the related Read-side behaviour.

Why the card looks smaller

• The image partition layout is smaller than the card. The image’s partitions end well before the end of the larger card, leaving unallocated space.
• Windows only mounts what it understands. A Raspberry Pi image, for example, has a small FAT boot partition that Windows shows, plus Linux partitions Windows does not assign letters to. Explorer therefore reports only the small visible partition.
• Disk Management tells the truth. Open Disk Management and you will usually see the small partitions plus a large block labelled Unallocated. That block is your missing space.
• A fake card is the exception. If Disk Management shows the card itself as much smaller than printed, or a capacity test fails, the card may be counterfeit rather than merely partitioned small. See how to test a fake card before assuming a partition fix will help.

Fixes, cheapest and quickest first

• On a Raspberry Pi, expand the filesystem from the Pi itself. Boot the Pi, run raspi-config, choose Advanced Options, then Expand Filesystem, and reboot. This is the intended fix for Pi images and it preserves your system.
• On Windows, extend the visible partition only if it is a Windows-readable partition you own. In Disk Management, right-click the partition immediately before the unallocated space and choose Extend Volume if Windows offers it. Do not delete a partition you do not recognise to make room.
• Use a partition tool for Linux partitions. If the unallocated space follows a Linux partition, a tool such as GParted (from a live USB) can resize that partition into the free space. Back up the card image first — resizing can go wrong.
• Re-image from scratch if you do not need the current contents. If the card holds nothing you need, you can repartition the whole card in Disk Management (delete all partitions, create one full-size FAT32 or exFAT volume) to prove the full capacity is present, then flash again and expand as above.
• Verify full capacity before trusting the card. After reclaiming space, check that Disk Management shows the full size and, for a new or suspicious card, run a full write-and-verify test.

Do not format the card in Windows as a first step if the card contains a system you want to keep, such as a Pi installation. Formatting the visible partition will not reclaim the unallocated space and may destroy the boot partition. Expanding is the fix; formatting is only appropriate when you are deliberately wiping the card to reuse it as plain storage.

If you need a fresh copy of the tool, use the download page. For other post-flash surprises, the troubleshooting hub and write succeeded but won’t boot guide cover the next most common cases.

When to stop and switch tools

Stop trying partition fixes if Disk Management shows the physical device itself as far smaller than the printed size, if the card reports different sizes on different PCs, or if a full capacity test fails. Those are signs of a fake or failing card, not a partition layout issue, and no partition tool will create real capacity that is not there. Replace the card. Likewise, if expanding repeatedly corrupts the filesystem, stop and take a fresh backup image first, then expand on a copy — a card that corrupts on resize is telling you it is unreliable.

FAQ

Did flashing shrink my SD card permanently?

No, in almost all cases. The card still has its full capacity; Windows is only showing the small partition that the image created. Re-partitioning restores the rest.

Is it safe to expand the partition on a Raspberry Pi card?

Yes, if you use the Pi’s own expand option or a trusted partition tool and you have a backup. Expanding does not erase the system partition when done correctly, but back up first anyway.

Why does the image not fill the whole card?

Because an image is a fixed-size snapshot. It was built for a smaller card or a fixed partition layout, so it only creates partitions of that size, leaving the rest unallocated.

Community reports consistently describe Error 121 as a USB timeout, bad-sector, or driver issue. That framing matters: these are reported causes from users, not certified bugs in Win32 Disk Imager v1.0.0 (2017-03-08, GPLv2, Windows-only). The program itself is a straightforward sector copier — it reads or writes the whole device in order — so when the device stops responding mid-transfer, Windows reports the timeout and the program cannot continue. Treating the symptom as a hardware or driver problem, rather than hunting for a hidden option, leads to faster fixes.

Why Error 121 happens

• Unstable USB connection. A loose cable, a hub, a front-panel port with a long internal cable, or a reader that briefly disconnects will break the transfer.
• Failing reader. Cheap or worn readers overheat or drop under sustained load, even if they work for copying a few small files.
• Failing or fake card. A card with bad sectors, worn flash, or far less real capacity than printed will stall or return errors part-way through a full-device write.
• Driver or power issue. An outdated USB controller driver, a USB power-saving setting that suspends the port, or a port that cannot supply stable power can all produce timeouts.
• Card removed or disturbed mid-write. Any movement of the card in the slot during a long write can interrupt the transfer.

Notice what is not on that list: the image format. Win32 Disk Imager does not parse ISO filesystems, and it copies the whole device sector by sector, but Error 121 is a transport failure, not a format error. If the image were unreadable, you would normally fail before the transfer starts, not minutes into it.

Fixes, cheapest and quickest first

• Do not touch the card during the write. Put the reader on a stable surface, do not move the laptop, and do not bump the cable. Retry once after a clean reinsert to rule out a one-off disturbance.
• Use a direct USB port, not a hub. Move the reader to a port on the PC itself, preferably a rear port on a desktop. Avoid unpowered hubs for full-card writes.
• Disable USB selective suspend for the test. In Windows Power Options, turn off USB selective suspend, then retry. If the write now completes, power management was suspending the port mid-transfer.
• Try a different reader before buying a new card. Borrow or buy a known-good reader and retry the same card and image. If the error disappears, the old reader was the cause.
• Test the card for faults. If the error follows the card across readers and ports, the card is suspect. Run a full read test — see how to test a fake or counterfeit card — and replace a card that stalls, drops, or reports far less capacity than printed.
• Update USB controller drivers from the PC maker. Use the PC or motherboard maker’s driver page, not a generic driver updater, and reboot before retrying.

If a different reader fixes it, that is a genuine hardware fix, not a workaround. A failing reader can also produce slow writes and intermittent drive-letter problems, so the same replacement often clears several symptoms at once. Readers and cards are the two hardware items worth spending on here: a reliable USB SD card reader (Sponsored) and, if the card itself is suspect, a durable endurance microSD card (Sponsored) are the sensible replacements, chosen for sustained-write reliability rather than headline speed claims.

Get a fresh copy if needed from the download page, and see the troubleshooting hub for related symptoms. Neighbouring guides that help isolate the cause include slow write speed and drive letter missing.

When to stop and switch tools

Stop retrying the same combination if you have changed the port, the reader, and the card, updated drivers, and disabled USB power saving, and Error 121 still appears at roughly the same progress point. A repeatable failure at the same point suggests bad sectors on that card or a drive problem that another imager will hit too. At that point, stop writing to the card, preserve any data you still need from it if it is readable, and replace the card rather than forcing repeated full-device writes. Switching tools is useful as a diagnostic — if a second tool fails the same way, the hardware verdict is confirmed — but it is not a cure for a failing card.

FAQ

Is Error 121 caused by a bad image file?

Usually not. Error 121 is reported during the transfer itself, which points to the USB connection, the reader, the card, or the driver rather than the contents of the image.

Should I keep retrying the same write?

No. Repeated retries on a failing card or reader can make things worse and waste time. Change one variable at a time — port, reader, then card — and test each change.

Does a new card reader really fix Error 121?

Often, yes, when the old reader is the weak link. Readers vary widely in quality, and a timeout that appears with one reader frequently disappears with another, which is why it is worth testing before replacing the card.

Win32 Disk Imager v1.0.0, released 2017-03-08 and released under GPLv2, is a Windows-only tool that reads and writes whole devices sector by sector. It does not work through ordinary file operations. To open a physical drive for raw access, Windows requires elevation. If you launch the program by double-clicking its icon from a standard user account, or from a shortcut that does not request elevation, Windows blocks the device open call and the program reports Error 5. That requirement is genuine: run as administrator is not a workaround, it is how raw disk access works on Windows.

Why Error 5 happens

• Not elevated. The program was started without administrator rights, so Windows denies raw device access.
• Another program holds the drive. Explorer, an antivirus scanner, a partition tool, or another imaging tool may have the card open, which blocks exclusive access.
• Drive-letter or device confusion. The selected device is not the card, or the card was removed and reinserted and Windows reassigned it while the program still points at the old handle.
• Policy or security software. On managed or locked-down PCs, group policy or endpoint protection can block raw disk access even for administrators.
• Failing reader or card. Less commonly, a flaky reader drops the device mid-open and Windows reports the failure as an access error.

Start with the simplest explanation. Most home users hit the first item, and the fix takes seconds. Do not reformat the card, do not download a different image, and do not assume the card is broken until you have tried the steps below in order.

Fixes, cheapest and quickest first

• Close Win32 Disk Imager completely, then right-click it and choose Run as administrator. Confirm the User Account Control prompt. Re-select the drive letter and the image file, then try again. This alone resolves most Error 5 cases.
• Close everything that might touch the card. Close Explorer windows showing the card, partition managers, backup tools, and any other imaging software. If an antivirus scan is running on the removable drive, pause it for this operation.
• Remove and reinsert the card. Use Safely Remove Hardware first if Windows offers it, wait a few seconds, reinsert the card, wait for Windows to recognise it, then relaunch Win32 Disk Imager as administrator and re-select the device.
• Try a different USB port and, if possible, a different card reader. Front-panel ports and cheap readers are common failure points. A direct port on the PC, rather than a hub, is the better test.
• Check that you selected the right device. Compare the drive letter and size shown in Win32 Disk Imager with what Windows shows for the card. If the sizes do not match, stop: you may be pointing at the wrong drive, and a write to the wrong drive overwrites the entire destination.
• Test the card in another PC if you have one. If Error 5 follows the card and reader to a second PC, suspect hardware. If it works there, suspect policy or security software on the first PC.

If you are on a work or school PC, you may not be able to fix this yourself. Raw disk access can be blocked by policy even for local administrators. In that case, use a personal PC you control, or ask the administrator whether removable raw-disk access is permitted. Do not try to bypass endpoint protection; that can violate policy and will not make the write safer.

For a full walkthrough of a normal write, see how to use Win32 Disk Imager — note that the tutorial link list uses the site hub structure; the essential steps are the same: run as administrator, verify the drive letter, then write. You can also get a fresh copy from the download page and return to the troubleshooting hub for related errors.

When to stop and switch tools

Stop troubleshooting Win32 Disk Imager itself if elevation, a clean reinsert, a different port, and a different reader all still produce Error 5 on a PC you control, and the same card works in another tool. At that point the problem is likely Windows policy, a driver conflict, or a failing card, and switching to another imager will not magically grant raw access either — but testing with a second tool on a second PC will tell you whether the card itself is readable at all. If no tool on any PC can open the card, treat the card as suspect and do not keep forcing writes to it. See also Error 121 and drive letter missing for neighbouring symptoms that often share a reader or hardware cause.

FAQ

Why does Win32 Disk Imager need administrator rights?

Because writing or reading a raw disk device bypasses the normal file system. Windows only allows that level of access to an elevated process, so running without elevation produces Error 5.

I ran as administrator and still get Error 5. What next?

Close any program that may hold the drive open, including Explorer windows, antivirus scans, and disk tools, then remove and reinsert the card and try again with a different reader if the error persists.

Can Error 5 damage my SD card?

No. Error 5 means access was refused before any write started, so the card contents are not changed by the failed attempt itself.