Blasting MBRs

Empty your hard disk to install a new OS

Installing and removing versions of Windows NT, Windows 9x, and Linux on a computer often leads to mysterious computer behavior. Recently, I thought that I had completely removed Linux from a computer, but the computer wouldn't boot without a Linux-ish error message. I zapped every partition and still Linux raised its head—despite a seemingly empty hard disk. PC veterans attribute mysteries of this type to an area of the disk called the Master Boot Record (MBR). Unless you know a few tricks, NT, other versions of Windows, and DOS lack simple tools for working with the MBR.

The MBR sits on your hard disk's first sector in a 512-byte area. The MBR provides a table of contents of the disk's partitions and their sizes. As a result, formatting the C drive to delete the MBR would be ineffective because the MBR sits outside the area of the disk known as drive C. Think of it this way: The MBR is a book's table of contents, and the C drive is the first chapter; ripping the pages of the first chapter out of the book wouldn't remove the first chapter's entry in the table of contents. The MBR has two parts: a short program that performs part of your PC's booting process and data that represents the table of contents.

In my case of trying to remove Linux, Linux modified the program inside the MBR, and the program emitted the error message. When you first try to fix a bulky MBR, try Fdisk. Fdisk is the only NT, Windows, and DOS command that directly affects the MBR. Fdisk has an undocumented option that replaces your computer's original MBR program: Run DOS or Windows, open up a command line, and type

fdisk /mbr

This procedure should replace the MBR, but sometimes it won't. Fdisk does a sanity check before writing out this program, and sometimes Fdisk decides not to rewrite the MBR's program. Unfortunately, that's the error message I saw when trying to use Fdisk on my Linux system. I have no idea why Fdisk decided not to rewrite the program. I've removed Linux from systems without getting back talk from Fdisk, but for some reason, Fdisk wasn't cooperating that day. I figured that the best approach was to wipe the MBR clean and rebuild the drive. But I had to figure out how to accomplish this task with Fdisk failing me. Time for Plan B and a little DEBUG magic.

Since 1983, Microsoft has shipped its OSs (i.e., NT, Windows, and DOS) with a helpful tool called DEBUG. A cool feature of DEBUG lets you create and execute small assembly language programs; let's create a program to delete the MBR's data. This assembly language program won't run under NT, so you need to boot Win9x or DOS from a safe-mode command prompt.

Before creating this program, however, let me stress a warning. This program intends to remove your hard disk's main table of contents. If you're successful, you will delete the entire hard disk. Don't try this procedure if you want to save your hard disk's data. This procedure is intended only for drives that you want to restore to their factory-shipped state.

At a command prompt, start DEBUG. You know DEBUG is running when you see a hyphen (-). The hyphen is DEBUG's way of saying, "DEBUG reporting for duty and standing by." DEBUG commands generally consist of one letter followed by letters and numbers. (By the way, the numbers will be in hexadecimal format.)

To zap a disk's MBR, you create an area in RAM that is 512 bytes long and fill it with zeros. Then, you write a short assembly language program to tell the PC to write that 512-byte area of memory to the first sector of the first disk. The first sector is sometimes referred to as sector 0/0/1. You identify sector and disk locations with three numbers: the head number (0 for the first head), the cylinder number (0 for the first cylinder), and the sector number on that particular head/cylinder combination (1 for the first sector). If you're wondering why we use 0/0/1 rather than 0/0/0, I don't know of a good reason; attribute it to a historical accident. We number heads and cylinders from zero, but we number sectors starting at one.

To create the zeroed-out area of memory, type

F 9000:0 L 200 0

DEBUG responds with another hyphen. You just created an area starting at address 9000:0 (addresses are always two numbers separated by a colon) that is 512 bytes long (200 in hex equals 512 in decimal), and you filled that area with zeros. DEBUG accepts uppercase or lowercase letters, but it needs spaces between parameters: One space between F and 9000:0, another space before L, another space before 200, and a final space before 0.

Next, you enter the assembly language program. The program tells the computer to copy one sector of data from 9000:0 to head 0, cylinder 0, sector 1. To start the assembly language program, you need to tell the computer to write the sector of data by invoking a built-in BIOS program in your computer's BIOS. The BIOS program is at software interrupt 13 (i.e., INT 13). To write out a sector of data, INT 13 must first know where to find the data. You tell INT 13 how to find the data by putting the data's address in internal CPU areas called registers BX and ES. Then, you tell INT 13 which drive, head, cylinder, and sector to write the data to by placing the data in two more registers, CX and DX. You then tell INT 13 to write (rather than read or some other function) and the number of sectors to write by placing the data in another register called AX. The command INT 13 says to execute the command. Tell the system to return control to you with another command, INT 20.

To tell DEBUG that you're ready to start entering assembly language code, type

a

and press Enter. The prompt will change from a hyphen to an address, such as 0267:0100. That address is where your system will store your command. To run the program, you must enter assembly language code into your computer's memory by typing the following eight lines:

Mov dx,9000

Mov es,dx

Xor bx,bx

Mov cx,0001

Mov dx,0080

Mov ax,0301

Int 13

Int 20

Each of these lines begins with Mov, Xor, or Int, followed by a space, and followed by one or more parameters separated by commas. Type the first line as Mov, followed by a space, and followed by dx,9000 without a space between dx and 9000. If you mistype a command, DEBUG responds with ^ Error. The circumflex (^) points to the parameter that it doesn't understand. (If you've entered assembly language with an earlier DOS version of DEBUG, you'll be pleased that the DEBUG version that comes with Win98 is a lot more forgiving. You can type movdx,9000 without any spaces, and DEBUG still figures out the exact syntax of the assembly language command.)

After you type the above lines, press Enter twice to return to the hyphen. You can check your work by typing

u 100 L 12

which stands for unassemble the 18 (hex 12) bytes starting at address 100. Press Enter, and you'll see what DEBUG thinks you typed. If you really messed up and you want to start over, type q (for quit) and press Enter; you'll return to the C prompt.

If you like what you see, you can activate the program by typing g (for go) at the hyphen and pressing Enter. You'll receive the message Program terminated normally. Your MBR is now wiped clean, and you can start installing NT, Win98, or another OS as if the hard disk were brand new.

I know the first few lines of the program look tortured: The first Mov dx,9000 places the value 9000 hex into the DX register; the next line puts the value of DX into the ES register. Why not just put the value 9000 into ES? Because of a quirk in the Intel architecture, you can't directly place data into the ES register except through other registers. The next line, Xor bx,bx, is a quick way to put the value 0 into the BX register. After ES contains 9000 and BX contains 0, then INT 13 knows where to get the data: ES, BX, or 9000:0. The next command, Mov cx,0001, is necessary because INT 13 expects the cylinder number (0) and the sector number (1) packed together into CX in that way: cylinder/sector. Similarly, Mov dx,0080 packs both the target head (0) and drive (80) into register DX. INT 13 refers to the first physical hard disk as 80, the second as 81, and so on. Mov ax,0301 once more packs two pieces of information into one register. INT 13 identifies the write sector command as function number 3. INT 13 needs to know how many sectors to write—one—and those two get packed together into 0301.

I figured out how to complete this process about 10 years ago. I don't use DEBUG often, but it saves me a couple of times a year; I hope it's useful for you. One more thing—please don't email me for Linux advice. I'm just starting out myself and couldn't be of much help. Happy MBR blasting!

Discuss this Article 15

Carl Jarnberg (not verified)
on Sep 2, 2000
Excellent! Cleared a Ntfs disk partition to allow full drive for FAT32. Thanks a bunch.
Mark Middleton (not verified)
on May 9, 2002
Thankyou, I installed linux as a dual boot o/s on my pc,it killed my MBR and made the drive unbootable.Have searched for hours trying to find a fix and this is the only way to do it. Thanks again
Paulo Farinazzo (not verified)
on Mar 31, 2003
Thanks a lot! Your assembly explanation was great for me !! I allways want to know how to write to a hard disk single sector and now I can do it!! Excellent !!
Kevin (not verified)
on Jun 21, 2004
Australian keyboards convert v to c and x to f to enable kangaroo typing...also helps wallabees. Could be you are so far down under that you are upside down whilst typing.
Ed Larkin (not verified)
on Sep 29, 2001
Fantastic!! I had an error in the MBR and couldn't FDisk the drive - even with the /MBR switch. A minute to type in the script and run it - and the drive is again useable. Thanks for saving the drive.
Anonymous User (not verified)
on Jan 9, 2005
Of all articles that I have read in search of help, this one is superior to all. This article shows that the writer knows his stuff. thanks a million
Mark Warbeck (not verified)
on Feb 23, 2000
This is the kind of practical information I subscribe for! This article saved my bacon again. I keep the debug code on a CD that contains my admin tools. Keep up the good work!
Clinton Meyer (not verified)
on Mar 24, 2003
I hope the author reads this, as MBR Blasting just saved my day again! Don't have to use it often, but when I do it has not failed me yet and does the trick *very* well. Thank you!
Anonymous User (not verified)
on Nov 1, 2004
I tryed the debug code, but it did not clean the MBR
Anonymous User (not verified)
on Dec 23, 2004
To Whom Wrote This: You are great! Thanks A Lot!!!!!!!!!!!!!
Dave Wilson (not verified)
on Apr 6, 2004
Brilliant!!! Genius article! Make sure you read carefully and understand fully before execution. Had a problem with converting a drive from Ext3 back to Fat32 where Partition Magic fell short. Thx for saving my ASCII! :)
Graham Schultz (not verified)
on Apr 27, 2004
Hi Mark, I am trying to enact your code as in this article. Mark Minasi Inside Out InstantDoc #5327 Blasting MBRs I am finding that if I put in the comand Mov dx,9000 I get an error on the o, If I change the o to a Zero the error moves to the v which I changed to a c ,, converting above to M0(=zero)c df,9000 it comes up with no errors , could you please tell me what I am doing wrong or send me the Item in an easier to follow format, I am using a win98 boot disk, Testing some of the other commands I still get errors on some of the other letters & no,s.entered. Hoping you can Help. Regards Graham Schultz, Australia
Todd Kuhn (not verified)
on Mar 22, 2001
Awesoem article! It may just be thing that I'm looking for, fdisk doesn't want to erase the MBR on my 3rd hard drive. But I'll give this a try. Thank you for the article! Todd
Anonymous User (not verified)
on Jan 12, 2005
great! old school style works great... fixmbr, fdisk /mbr, lilo, etc...etc... did not report any error - but still my drive was NOT bootable... until I found this superbe article! cheerio from switzerland guschti
John (not verified)
on Nov 26, 2007
Is that all in this article? The dots at the end suggest more content, but can't find it. Not impressed.

Please or Register to post comments.

Upcoming Training

Mastering System Center 2012

During over 6 hours of training you can join John Savill from your computer as he will walk you through the key components and capabilities of System Center 2012, what’s involved in using the components, and the benefit they can bring to your environment.

Register Now

Current Issue

May 2013 - The NameTranslate object is useful when you need to translate Active Directory object names between different formats, but it's awkward to use from PowerShell. Here's a PowerShell script that eliminates the awkwardness.

CURRENT ISSUE / ARCHIVE / SUBSCRIBE

Windows Forums

Get answers to questions, share tips, and engage with the Windows Community in our Forums.