diskpart clean zeros LBA 0 to LBA 2047

During the course of this thread Recover data from a diskpart > clean command it became evident that the first NTFS (also known as Partition Boot Record / Volume Boot Record) in a HDD can be at LBA 63 (Absolute Sector 63) or LBA 2048 (Absolute Sector 2048) depending upon the partitioning utility used. This is actually the starting sector of the first partition.

Partition Wizard run from a bootable pendrive formatted a 750GB Seagate GoFlex external HDD with the first NTFS at LBA 63.



Windows Disk Management formatted the same drive with the first NTFS at LBA 2048.



In both cases it was found that the diskpart clean command zeroed LBA 0 to LBA 2047.

This should remove the common misconception that the diskpart clean zeros only the MBR at LBA 0.

Even I believed it to be so thus far till a debate/discussion between me and Anshad Edavana in that thread brought this revelation.

I did one more DISKPART experiment with a XP partitioned disk ( partition start at LBA 63 ). Regardless of the starting position of first partition at LBA 63, DISKPART zeroed the first 1 MB and last 1 MB. It looks like this behavior is hard coded in "Windows 7" version of DISKPART ( Probably in 8 too ). It make sense because DISKPART doesn't have to bother about whether the disk is partitioned in MBR or GPT scheme by wiping out first and last one MB.

Official Microsoft documentation ( DiskPart Command-Line Options ) start by these words:

DiskPart is a text-mode command interpreter in Windows Vista, Windows® XP, and the Windows Server 2003® family

It means the documentation was probably updated lastly on 2006. Even at the time of Vista, GPT was not popular and large capacity drives are very rare. Anyway since both Vista and XP are obsolete, there won't be any practical benefit in examining how legacy version of DISKPART works.

For some years here we've used Diskpart Clean command heavily to overcome more than half of installation failures as well as occasionally when a drive is traced as blocking boot. I assumed it was because interfering boot code was neutralized along with possibly the partition table.

Does this prove or disprove that theory, or shed any more light on exactly why Clean command works for these purposes?

Nice work.

I don't know what the charts mean and never will.
I'm trying to understand what is trying to be proved and why.
I have followed the other thread for days trying to learn something but I'm still lost. Could you explain it better with less teckie?

Typically a hard drive's sector is 512 bytes sized. As you know, sector 0 is reserved for MBR and all legacy operating systems like XP, DOS etc creates first partition at sector 63. There will be a 62 sector gap between the MBR and partition one. Windows usually considers this as "hidden sectors" but Linux may use these sectors to store parts of GRUB.

The default behavior of creating first partition at sector 63 is changed with the release of "Vista". By default, Vista and higher operating systems only creates partitions starting from sector 2048. The reason for this is to maintain compatibility with modern "Advanced Format Disks" and Solid state disks. All partitions created under Vista/7/8 using either installer, Dikpart or Disk Management will always start on a number divisible by 8.

If we issue DIKPART CLEAN command from "Windows 7" or it's install disc, first 1 MB ( LBA 0 to 2047 ) and last 1 MB seems to be filled with zeros. Sector 2048 and onward won't be wiped unless we use DISKPART CLEAN ALL command. When we scan for lost partitions with "Partition Wizard" or "TestDisk", both will search for NTFS boot sectors starting from sector zero and probably will find the first partition's boot sector on LBA 2048 and parse partition information by reading it. Then this info is used to create a new partition table entry.

On the other hand if we issue DISKPART CLEAN command against a disk which is partitioned by legacy partitioning tools ( XP setup, Partition Wizard Bootable CD etc ), NTFS boot sector which starts at sector 63 will be zeroed as part of first 1 MB wipe. So the chances of successfully recovering the partition will be marginally low. In my test, "TestDisk" was able to find the partition by locating the backup copy of boot sector but it took a long time to do that.

For whatever reason a deep scan with neither "TestDisk" nor "Partition Wizard" failed to find the lost partition in OP's external HDD. This may happen if both primary and backup "Boot Sectors" are damaged.

Layback Bear said:

...... What would a dummy like me do with this information?
Where would it come in handy for a dummy like me?

The message is loud and clear. Do what a dummy like me does.:)

Know your HDD.

By that I mean check each and every HDD you have. Know whether the start LBA of your partition is LBA 63 or LBA 2048. Make a note of it.

If it is LBA63, don't run diskpart clean on it under any circumstances - even if recommended by a Microsoft Certified Professional.

gregrocker said:

For some years here we've used Diskpart Clean command heavily to overcome more than half of installation failures as well as occasionally when a drive is traced as blocking boot. I assumed it was because interfering boot code was neutralized along with possibly the partition table.

Does this prove or disprove that theory, or shed any more light on exactly why Clean command works for these purposes?

Nice work.

If one suspects boot sector related problems or Windows booting related problems :

If it is an already existing HDD with a single volume or multiple volumes, it shall be prudent to examine the start sector of the first volume ( this I would presume can be done in many ways. Even by running a partitioning utility from a boot device. The properties of the volume may show the start sector) and recommend diskpart clean only if the start sector is LBA 2048. If it is LBA 63 it is a no no as it will zero it and make the disk inaccessible. This may perhaps increase the success rate from the present estimate you had indicated by eliminating one cause of failure of recommended action.

In the case of start sector LBA 2048 drives - Many alien OS like Linux may write data in Sector 64 to 2047 and any dirty data left behind may be a potential source of Windows booting related problems. So wiping it with diskpart clean may be advantageous. (E & O.E. - Errors and Omissions Excepted. )

We already seem to have another problem of this kind here where another forum had recommended diskpart clean. DISKPART clean performed accidently. how to recover data? I am just closing my eyes. I need sometime off. I can afford to now that Anshad is here to battle.:)

How will running Clean command make a disk inaccessible? I've never seen this. It appears from your discussion it would make the data irretrievable by undelete but that is not what we're attempting to do in installation troubleshooting where we only need the MBR boot code and Partition Table zeroed.

Are you saying that to Clean a disk with LBA 63 would make the disk inaccessible to use at all? I've never heard of that.

Are you saying that to Clean a disk with LBA 63 would make the disk inaccessible to use at all? I've never heard of that.

Possibility for a successful recovery depends on more than one factor - especially the presence of a valid backup boot sector and the contents of LBA 64 to 2047. These sectors will be part of NTFS (if partition start at sector 63 ) and may or may not used to store critical file system structure data.

In my test, i was able to successfully recover the partition since backup boot sector was not destroyed. However Windows refused to recognize the NTFS due to the wiped out sectors inside the file system ( LBA 64 to 2047 ). Fortunately running CHKDSK was able to successfully repair the damage and all files were in tact.

But the backup boot sector may also be destroyed if it is stored at the very end of the disk. In that case partition recovery will be very difficult if not impossible.

I only asked if these findings reveal any more about why Clean command works for Win7 installation failures. I am not contesting anything about partition recovery, but am trying to understand better how exactly Clean command works to resolve installation failures.

I think Kaktussoft answered it in another thread:

Kaktussoft said:

gregrocker said:

Would you want to theorize why Clean command works to overcome about half or more of all installation failures? I assume it's because it wipes boot sector and the partition table, one or both of which interferes with attempts to install Win7.

Likewise on multiple occasions we've had drives which failed to boot that traced to a hard drive where the solution was to wipe the drive with Clean command.

After the diskpart->clean command the MBR, so master bootcode and partition table, is zeroed. Both are in sector 0. So "logically" the disk is totally empty. It doesn't have boot code and no partitions at all afterwards.

Do you concur?