I am trying to use the windows version of dd to copy a RHEL iso to a USB stick. However, I wanted to zero out the drive first to ensure there is no filesystem on it before writing it out. Is there an equivalent of /dev/zero in windows that I can use as the infile?

6 Answers 6


John Newbigin's dd supports this.

Virtual devices are a new feature in version 0.4beta1.

Because windows does not have devices like the unix /dev/zero or /dev/random these have been implemented inside dd. You can use these as input files to supply an infinite amount of zeros or pseudo random data.

  • Worked like a charm, it's zeroing out now! Thank you for the heads up!!!
    – Matthew
    Oct 14, 2011 at 14:04

There are also some actual device drivers for /dev/zero as well as /dev/random under Win32.


I suggest the very useful sdelete utility

It can zero free space or clean it (via multiple random passes).


dd /dev/zero is referred to as Forensic Wipe and is typically done before forensically imaging data from one device to another in order to mitigate cross contamination. This includes new devices freshly removed from their packaging due to manufacturer files and so forth.


Download "dd for Windows" and open Windows Command-line ("cmd.exe").

Type: "cd /D [directory]" to the "dd" folder.

Type: "dd --list" to show list of Volumes, Disks, and Partitions. Locate your device.

Type: "dd if=/dev/zero of=\\?\Device\Harddisk1\Partition0 --progress"

Choose between "/dev/zero" and "/dev/random" as the write operation. Ensure you select your device based on step 3.


Wait for the zero or random write process to complete and then run hexdump to display hexadecimal value, which should read all zeros for "/dev/zero" process. Choose one of the following:

Type: "dd if=\\?\Device\Harddisk1\Partition0 | hexdump -C"

Type: "hexdump.exe -C \\.\d:" where [\\.\d:] is [unformatted directory]

The result of Zero Write using "dd if=\?\Device\Harddisk1\Partition0 | hexdump -C" and will continue parsing zeros (null data) until the end of the drive. The drive used in the image was NOT formatted after executing the Zero Write procedure. The following image depicts what would be considered a Zero Write success: https://i.sstatic.net/idpHc.png

The hexadecimal printout result after ONLY formatting the drive. This shows any alteration to the drive contents will trigger a printout instead of running through the entire drive showing all zeros (null data). The following image depicts what would be considered a Zero Write fail: https://i.sstatic.net/JghoO.png


The drive must be in an unreadable state (RAW - format drive before use) otherwise "Error native opening file...operation completed successfully" or "Error writing file...Access is denied" will result without any action taken using the Windows based "dd" tool.

The easiest method for placing the drive into RAW state is to execute the "/dev/zero" process explained above, it will immediately fail, then remove and reinsert the drive. The "format before use prompt..." will appear, click cancel, and then repeat the same "/dev/zero" process to either write zeros (null data) or pseudo-random data to the drive.


You can simulate a /dev/zero with Busybox-w32, although I'm not sure whether it can or not zero-fill storages:

while printf '\0'; do printf '\0'; done | dd of=<file> bs=4M conv=sync status=progress


yes "" | tr '\n' '\0' | dd of=<file> bs=4M conv=sync status=progress

If you don't mind installing a full GNU/POSIX environment, Cygwin provides special (/dev/zero, /dev/random and /dev/urandom) and physical (/dev/sdX) devices.


What you are trying to do is absolutely pointless, regardless of medium (why zero out whatever, when I'm gonna overwrite it in a second ?). Zeroing before write just adds a slight check that two writes succeeded (and it steals some of your precious time).

And it is (if possible) even more pointless in context of solid-state / flash drives. Most of them will, on write, choose one of the free, least used blocks (they actually have more capacity then advertised, just as HDDs have space reserved for remapping of bad blocks), write the content to the new block, remember that this block now stores content of "offset xyz" and release the old block to the "free pool".

Even when they are sent a "trim" request (mark the block as free and zero it out), a lot of flash drives take the approach "yeah, I'll do it some time in the future, when I'll feel like it".

Some will actually do nothing (not even keep a note they were ordered to zero out some area) when you unplug them "soon enough" after requesting a/some trim(s) - and "soon enough" here means "[even tens of] seconds after the request".

So just overwrite (regardless of the drive type), no zeroing necessary or (from now on it's about flash drives) even easily possible. When you require a safe wipe, look whether the drive manufacturer provides some utility to do this, that would take care to really zero out all of the areas of the drive ...

  • While correct, this doesn't answer the question. There might be other, more useful reasons to have /dev/zero.
    – Sven
    Aug 6, 2015 at 12:26
  • @swen Well, the question in whole is wrong/pointless. I felt it was necessary to point it out in so no-one else would repeat the same pointless dance. Of course, it brought up interesting answers, so I didn't mark the question as pointles, only the reason for the question ... Aug 6, 2015 at 13:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .