• DO NOT run "chkdsk" or "scandisk" or any other partition repair utility
• DO NOT use the Windows recovery console commands "fixmbr" or "fixboot"
• DO NOT attempt to recreate a deleted partition with "Fdisk" or "Disk Management"
• DO NOT change the contents of the disk or partition that needs to be recovered

If you need help diagnosing the problem please look here to find out how to get started.

STOP using it immediately and do not attempt any software based recovery! Recovering data from a physically defective disk is very expensive so consider the need for this type of recovery carefully.

The hard disk spins but is not detected in the BIOS:

This can be caused by a number of things ranging from defective IDE cables to physical damage:

• Make sure the drive is properly configured in the BIOS (the AUTO setting should do well in most circumstances)
• Make sure the drive is properly jumpered
• You can try if the disk is detected using different hardware; a different PC, different cables etc.
• Use diagnostic software like HD Workbench or a drive manufacturer diagnostic tool; If HD Workbench sees the drive see if you can clone it.

Sometimes swapping the drive circuit board with one from an identical disk (type AND revision) can resolve this.

Drive doesn't spin up:

Consider if the value of the data outweighs the cost of data recovery by an outfit equipped to deal with physical defects (expertise, tools, cleanroom environment etc.).

Drive contains unreadable sectors:

Clone the drive immediately using DiskPatch. If required repair logical structures on the clone or extract data from the clone using a tool like iRecover.

Successful recovery of deleted files depends on certain factors:

• The file system type that is in use (FAT or NTFS)
• The level of fragmentation
• Is all data still available (or already overwritten)

Background: when formatting a drive a large portion of the administrative and meta information is re-initialized, but not all of it. Whether recovered data will be intact highly depends on the fragmentation of the file system: since there's no way of telling exactly what clusters "belonged" to specific files, recovery software will assume that the file system was not fragmented and files were stored in consecutive clusters. The effect of fragmentation on the quality of the recovered files is higher for FAT(32) than it is for NTFS.

What to do: if the partition was reformatted with a different file system, or the same file system using different parameters (for example different cluster sizes) than this will further complicate the recovery. When the program used for the recovery allows it (as iRecover does), specify exactly what file system you are "looking for". So if for example a FAT32 drive was accidentally formatted NTFS, tell the software to "treat" the partition as if it were a FAT32 drive.

The only way to verify if files can be recovered intact is by trying. In general, if the FAT(32) drive was recently defragmented chances for a good recovery are high. Large files have a higher chance of being fragmented and so have files that are frequently modified. Again, for drives that were originally formatted NTFS, this is less of an issue.

For this specific scenario we advise against the use of tools that attempt "in place" repairs; that is, tools trying to repair the file system. In general those repair attempts are almost never successful and they can't be undone, which in the end makes data recovery even harder.

Suggested tool for the job: iRecover.

Successful recovery of deleted files depends on certain factors:

• The file system type that is in use (FAT or NTFS)
• The level of fragmentation
• Is all data still available (or already overwritten)

Background: when a file is deleted its actual contents initially remain intact. However, in the partition's book-keeping of clusters in use by the file, these clusters are marked as free for use. The deleted file's name is modified so the deleted file no longer appears in the directory list. As it is no longer known exactly what clusters "belonged" to the deleted file, the successful recovery of files that were not stored in consecutive clusters is uncertain. If fragmentation is high the chances of a good recovery become less.

What to do: whatever tool you use to undelete files, do NOT copy the tool to the partition from which the files were deleted, and do not recover the deleted files by copying them to another folder on the same partition!

Normally you can repair this type of damage with DiskPatch by rebuilding the partition table. Alternatively, you can extract data rather than fixing the damaged disk using iRecover to copy data from the deleted partitions to another disk.

Please note the functional difference between the two approaches:

• DiskPatch repairs structures on-disk, thus changing the contents of the disk. Changes made by the automatic repair can be undone.
• iRecover extracts files from the disk, not changing the contents of the disk.

Which approach to take depends on the nature of your problem (and perhaps even personal preference). When posting a request for support, we will suggest which tool is best suited for the job.

You can verify if the software actually runs and detects your disks by running the demo versions. The demo versions will give a fair indication of the possibility of data recovery:

• You can test to see if the physical disks are detected; if the demo version does not find the disks, the registered version won't either
• They will detect or not detect lost partitions; if the demo version does not find any partitions, the registered version won't either
• Using the demos (DiskPatch especially) you can generate log files: you are welcome to submit the log files to us, we will always give a fair assessment of the chances for a successful recovery.

Scenario:

A RAID 0 array is no longer valid or detected as an array. Using the RAID setup configuration to re-create the array results in a warning message indicating that all data on the disks will be lost.

Solution:

Even after continuing and ignoring the warning message, users frequently reported that DiskPatch was able to recover all partitions on the re-created array using the "normal" procedures for recovering lost partitions.

Explanation:

It appears only the MBR on the array was blanked and this resulted in data loss. DiskPatch can almost always recover all partitions after they were lost due to a wiped MBR. Whether DiskPatch does this on a disk or a hardware RAID array makes no difference.

First, make sure there is no diskette in the floppy drive. If there is, remove the diskette and reboot your computer. If the problem persists and is not floppy related, do the following:

Important! Do not perform any of the following actions if the partition can not be accessed!

• Boot the computer from the Operating System boot diskette. Run Scandisk on the C: drive to detect and repair any disk errors.
• Make sure your hard drive is not compressed and that no anti-virus programs are running.
• Insert a bootable diskette that contains the same system files as the operating system on your hard drive. For example, if you have Windows 95b on your hard drive, insert a bootable floppy that was created using Windows 95b.
• Run the program "SYS.com" as follows: type "SYS A: C:" <enter>. The file SYS.com can usually be found in the c:\Windows\Command folder.
• The necessary system files will be transferred from the floppy to the appropriate location on your hard drive. When the process is complete, remove the bootable floppy and restart your computer. You should now be able to boot your operating system.

Note that damage to the partition's boot sector may be beyond what can be repaired by using the above procedures. For instance, damage to the BPB (which contains important meta information about the file system) can not be repaired this way; this type of damage can often be repaired by DiskPatch.

NTLDR -- The "NT Loader" takes control of the entire boot process until control is given to NTOSKRNL.EXE. (This occurs when the NT system menu option is selected.)

BOOT.INI -- This file contains the location of the NT boot partition and displays the menu options on bootup.

BOOTSECT.DOS -- This file takes control from NTLDR if you are running an operating system other than Windows NT.

NTDETECT.COM -- This file detects the installed hardware and adds the hardware list to the registry.

If any of the above files are missing or corrupt, an error message will be reported that may prevent Windows NT from loading properly. The following paragraphs outline some common error messages and their solutions.

"Couldn't find NTLDR. Please insert another disk."
This error message will occur during bootup if NTLDR is missing, or if there is a diskette in the floppy drive. To solve the problem, run an NT Repair.

"Windows NT could not start because the following file is missing or corrupt: winntrootsystem32ntoskrnl.exe"
This error will almost always indicate that the boot.ini is pointing to the wrong partition. It can also be reported if NTOSKRNL.EXE has become corrupted. To solve the problem first verify that the boot.ini points to the boot partition. If the boot.ini is correct, run an NT Repair; if the NTOSKRNL.EXE is corrupt, it will be repaired.
Note: If the BOOT.INI is missing, NTLDR will attempt to boot NT from the default directory of the active partition. If this fails, the above error message will also be reported.

"I/O Error Accessing Boot Sector File..{ARC Path..}"
This error message will occur when attempting to boot to another operating system other than Windows NT. This occurs when BOOTSECT.DOS is missing. To solve the problem run an NT Repair.

"NTDETECT v1.0 Checking Hardware...NTDETECT failed"
This error message will occur if NTDETECT.COM is missing or corrupt. To solve the problem run an NT Repair.

By following these steps, you increase your chances of a successful recovery and work in the safest manner possible!

Note: this article does not address "boot-issues" (software / O.S. related startup problems).

Step 1: Cloning

Cloning the disk (if possible) should always be the first step in a recovery process. Since you can then perform the recovery on the clone, the clone provides you with a safety net: if the recovery damages the clone, the original is not lost and you could create another clone. Also, cloning the problem disk might give you some additional information about the problem disk, like the status of the disk surface, the status of the controller or the status of the disk itself (screechy noises, clicking noises etc.).

When a disk is going bad (bad sectors appear and/or data becomes unreadable) cloning the disk is vital because each read on the problem disk may generate more damage. In fact, a dying disk should be treated as if the next read action will be the last read action.

To reduce "noise" caused by data that is already present on the destination disk it is advised you wipe the destination disk first. By wiping we mean that all sectors on the destination should be zeroed, only deleting the partitions or reformatting partitions on the destination disk is not sufficient! By wiping the destination disk you also verify the condition of this disk.

Both disk cloning and wiping can be performed using DIY DataRecovery DiskPatch.

Step 2: Diagnosis

The first thing that needs to be determined is the physical condition of the problem disk. As mentioned, observations made during the cloning process can provide useful information.

If your tool of choice to clone the disk doesn't detect the disk there are probably electronical or mechanical defects. If the disk is detected but the disk produces abnormal noises (clicking, scratching), the disk is physically damaged. If there is no sound at all, the disk is not spinning up.

If the disk isn't detected, produces noise or doesn't spin up, you should send the disk to a data recovery company that is equipped and qualified to deal with this. For example, DiskLabs.

If the disk can be read and the cloning tool creates a log file, this log file may include information that is useful for assessing the problem. When requesting support always include the relevant log file (DiskPatch creates a detailed log that contains information on what could and could not be read, always include this log file when requesting support).

If the cause for the data loss is known, for example because you have accidentally deleted a partition that you shouldn't have deleted, the diagnosis is pretty straightforward. If data just disappeared "all of a sudden" additional examination and analysis is required.

Avoid these common mistakes:

• If you are using "on-board" partitioning tools to assess the situation, be very careful; for example Fdisk deletes key structures when re-creating a partition. You will re-create the partition, but lose its contents!
• Running on-board or 3rd party "diagnostics and fixers": by this we mean Windows Chkdsk, Scandisk or 3rd party Chkdsk utilites like Norton/Symantec Disk Doctor. If one or more volumes can not be accessed, do not use any of the aforementioned utilities! If those utilities were already used and as a result files disappeared, the contents of those files may have been written to .CHK files. To determine if .CHK files contain usable data you either need to open those files (with a binary file editor) and manually inspect their content, or a specialized tool like CHK-Mate can be used. Note that if files were fragmented before Chkdsk or Scandisk was run, the contents of a file may be scattered among multiple .CHK files.
• The Windows Recovery Console's Fixboot command; this command frequently makes the damage worse! Do not use this command if a volume can not be accessed!

Your first step (after you have cloned the disk) is to verify if volumes or partitions are present. Each disk must contain at least one partition or volume before it can be used for data storage. A partition/volume is defined in the partition table. In Windows 2000/XP/Vista/7/8 a volume can also be defined in the LDM database; managing the LDM database is handled transparently by the Windows Disk Manager.

In general a volume or partition is assigned a drive letter (by the operating system) through which you can address the volume. If you are no longer able to boot the operating system you need to boot the PC from a diskette or bootable CD.

FAT and FAT32 partitions/volumes, if present and intact, can be accessed using a DOS boot diskette. DOS can not access NTFS volumes without the help of a driver (for example NTFS4DOS, currently supported by Avira).

If one or more volumes or partitions can not be found, the problem is probably in the partition tables. Even if the damage extends beyond that, the next step is determining the partition locations (their start position, their size). DiskPatch can be used to get additional information about the partition tables, and DiskPatch can rebuild the partition tables.

If ALL volumes can be found but one or more volumes can not be accessed, the damage is probably specific to those volumes (the boot sector, the FAT, the MFT, etc.). DiskPatch is often able to indicate if the problems come from a damaged boot sector, and several types of boot sector damage can be repaired by DiskPatch.

If all volumes are found and can be accessed while only a few files or folders on a particular volume have disappeared or can not be accessed, there is probably only minor file system damage (FAT, MFT or directories are damaged to some degree). In this case running a DiskPatch surface scan can reveal if this damage is caused by unreadable sectors.

Step 3: Repair or Extraction

- Repair:

Before attempting in-place repairs you should verify that the repair utility has an undo feature! As stated earlier, the safest way to conduct repairs is to work on a clone. At the very least, the software used to perform the repairs should create backups of areas that are repaired or allow the user to backup areas of the disk he or she is modifying.

In our experience it is safe to make in-place repairs if the data loss is caused by a corrupt master boot record, corrupt partition tables or a corrupt boot sector. It is this type of repair that DiskPatch can be used for. DiskPatch fixes the partition tables and boot sectors, after the user has selected which partitions to repair. DiskPatch allows the user to create a clone, and can undo all modifications made during the automatic repair.

- Extraction:

If in-place repairs are impossible or undesired, software like iRecover can be used to extract data from the damaged disk, and copy it to an intact disk.

Software like iRecover scans a disk to determine volume locations and their file system specific parameters. Since files are addressed using cluster addresses relative to the start of a data area (like the O.S. does), it is vital that the correct start and end values for a partition or volume are known, and that the software is able to determine the cluster size even if the boot sector is damaged.

If damage extends to the file system's main bookkeeping structures (FAT, MFT), recovery of fragmented files may be impossible (the files may be recovered, but they're probably corrupt/incomplete).

Sometimes all vital file system information can be lost. In this case it may still be possible to recover certain files based on their headers (recovery software checks the file's contents to see what type of file it is and then copies the connected clusters to a file). With this type of recovery file sizes and filenames are often generic. After the files are recovered they must actually be opened one by one to determine their content.

After files have been recovered, and before re-formatting the problem disk (if possible or desired), the recovered data needs to be verified! It may appear files were recovered (the folder structure is present, files with recognizable names are present), but this is no guarantee the files are actually intact.

Geometry consists of 2 values: heads (per cylinder) and sectors (per track). These values can differ from disk to disk, but are generally 255 (heads) and 63 (sectors). Although modern operating systems don't need to do this anymore, these values are still used when creating (basic) disk partitions. As such it is important that the PC has the correct values for the disk; if the values are wrong the operating system will not be able to find certain important structures on the disk and fail to boot, or even fail to access the partition completely.