here, explains in full.
"you also need to understand something about the typical disk layout of these structures.
Since DOS 3.0 the DOS boot sector has conventionally started at the first sector of a track (often 1,0,1, but never count on it). This has meant that all of the first physical track except the MBR (first sector) is "wasted space."
Now, on to what FDISK/MBR does...
Normally it overwrites what would be the DOS pre-bootstrap code part of the MBR, leaving the partition table and signature mentioned earlier.
Generally though, it sounds fairly harmless, right? "Generally" it is, and that explains why on many, many machines thousands of people have ignorantly done no damage to their drives.
The problem is, there are an awful lot of machines where my earlier description of the MBR contents and the layout of things on the first track of the hard drive do not match what FDISK is programmed to assume, and, as an Information Technology professional, I cannot conscientiously recommend something that can trash someone's disk without giving them a clear understanding of the possibility of making matters worse. This is why I refuse to post submissions that basically just say "Try FDISK/MBR" in response to "How do I clean <some boot virus>?" questions.
Examples of things that can go wrong and what happens:
A security system that does on-the-fly encryption and decryption of the hard drive may be installed with a pre-OS "driver" loading from the MBR bootstrap code. Such a scheme, being non-standard, has its own special MBR bootstrap code. Such code is typically much more than one sector (512 bytes) and as there is no DOS to interpret the file system, the "driver" is usually stored in the "wasted space" on track one (after the MBR) I referred to earlier. (A dual-boot MBR, e.g., OS/2, is another example that might fit into this category.)
You will lose access to your drive, at least until appropriate actions can be taken to reinstall the encryption software. Well-designed software of this kind will have been designed with data-integrity as well as security in mind so should have install options to allow reinstalling over a "corrupted" setup. Once FDISK/MBR has been run, the hard drive will most likely be completely inaccessible (after all, this is the point of most disk encryption schemes). Given someone was ignorant enough to corrupt it in the first place, what do you reckon the chances are they will have any idea they had a disk encryption scheme in the first place? (Or, at least, what are the chances they know how to have the installation fixed?)
A virus that does not preserve the original partition table in the right place or that encrypts it.
How many people do we get here [posted in the newsgroup comp.virus] per year with horror stories of "losing their C: drive" after FDISK/MBR against a Monkey-infected drive (or several other quite common viruses that also do not preserve the MBR in place)? These are usually quite easily fixed once someone who really knows what they are doing gets involved (unless the "expert" who just trashed the disk insists on continuing...).
A pre-OS driver to support "large drives" has been installed so a drive greater than 528MB can be used in a machine with an "old" BIOS. The mechanism for this is much the same as in 1 above.
Such large disk drivers (which are effectively a software BIOS extension) are quite common. (Anyone with a machine more than about 18 months old who has "upgraded" their hard drive is likely running one.) FDISK/MBR removes the driver that correctly allows access to cylinders 1024+, but the effect of removing it varies depending on all kinds of variables to do with the machines BIOS, the way the drive was partitioned, etc. As with encryption systems, many users of such large disk drivers have no idea that they are running one--after all, computers are just "tools", you don't have to understand how they work to use them. Because the driver load mechanism is similar to the security products mentioned in 1, similar comments apply about fixing these should they be damaged by an unwanted FDISK/MBR.
A virus that leaves the partition table in place, but stores critical viral variables in what is normally the bootstrap code portion of the MBR. A particularly nasty possibility here is that a virus may be running on-the-fly encryption/decryption of the drive's contents using an encryption key that was randomly generated at infection time.
At least one family of "in the wild" viruses, One_Half, does what I described here. FDISK/MBR against a drive infected with a One_Half variant (or any future/unknown virus that uses a similar "trick") will remove the MBR infection (One_Half is multi-partite, so it doesn't necessarily clean One_Half completely), but leaves you with a hard drive whose contents are partially encrypted with a now unknown and irretrievable key. This is definitely a case of the "cure" being worse than the disease!
Some antivirus (or general "system integrity") software may have loaded a special MBR to allow itself to check for possible MBR infection/change attempts.
FDISK/MBR against such integrity systems has a wide range of effects depending on the design of the system, from simply warning you of a change to the MBR to completely locking you out of your hard drive until the system is reinstalled/reconfigured.
A currently unimplemented virus attack I will not describe in detail here.
I know of a boot virus attack that has only been partially implemented in a real world virus to date, where FDISK/MBR would apparently clean the virus, but on rebooting from the hard drive, the virus would be able to reinstall itself and would "know" that a (clumsy) disinfection attempt had been made against it. If the virus' author was so inclined, this could be used as a trigger for some nasty payload (like reformatting your drive).
I could have named examples of the first five, though the risk in doing that is people who do not know better will think they are the only possibilities, rule them out and blunder on.
Just in case it is not clear at this point, all of these things replace (part of) the "normal" bootstrap code in the MBR with their own code and/or data and in some way critically modify the function of the bootstrap process.
Now you understand why FDISK/MBR is DANGEROUS!
<End quote>
Bottom line:
Don't Use FDISK /MBR!"
http://www.cknow.com/vtutor/vtfdiskmbr.htm
<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>
a virus can cause that. 
Facebook
Twitter
Instagram