I have a Western Digital SE 200GB (WD2000JB) hard drive, with 1 partition (not ideal I know!) as a slave with no operating system on it, storing media files (inc. AVI, MPEG, MP3, PDF, RAR, ZIP, EXE).
Then one day I get an error in the Event Viewer:
Event ID: 55
Event Source: NTFS
Event Description: The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume :.
- AND when trying to access this partition, I get the error " is not accessible. The file or directory is corrupted and unreadable"
- AND Windows 2000 recognises the file system as "unknown" and 0 bytes
I have tried almost EVERYTHING (except format and start again which I need to avoid!)
- hard drive diagnostics conclude that the physical hard drive is fine so it MUST be a corrupted NTFS file system
- ran chkdsk, but get error "corrupted master file table" - chkdsk is unable to read drive
- checked cables (hardware) connected fine
- recovery console doesn't allow access to the drive also, although 'fixboot' has allowed the drive to be recognised as an NTFS file system in Ontrack's EasyRecovery Pro software but not Windows 2000 or XP, hence is still not accessible! ('fixmbr' was useless too!)
- moved the hard drive into my Windows XP PC which recognises it with a "RAW" file system with 0 bytes and still cannot access it
So then, I tried DiskPatch 2.1 demo... selected the physical disk -> scanned the disk and selected the 1 NTFS partition it found, but it marked YES under the ERR column -> Show Info gives a "poor" prognosis & details the error as "End Past EOD" & won't let me continue to repair - What does this error mean? Can anyone help with my situation please?
Thank you in advance.
P.s. I have bought another 200GB drive and will sure be employing a backup strategy as soon as I get my data back! ;o)
Product you are using: DiskPatch 2.1
Operating system / Service Pack: Windows 2000 (SP4)
The problems appears to be that the BIOS does not support 48 bit LBA addressing, and that as a result of that we can not see the entire disk (just the first 128 Gb).
For DiskPatch to be able to see the entire disk, you'd need to see if a BIOS upgrade is available, or you'd need to add am add-on disk controller to the system capable of 48 bit LBA addressing.
Side note: Even if you decide not to use DiskPatch, it is wise to ensure the syste fully supports 48 bit LBA addressing. This means, the BIOS *plus* the OS need to be capable of 48 bit LBA addressing. See http://www.48bitLBA.com for more info on the matter.
Now will DiskPatch be able to help once you have taken care of all that? We can't tell until we see a logfile of that situation. Once we have that, we can tell if the non-existing boot sector for the NTFS partition can be fixed. For the NTFS partition we can ONLY find a partition table entry. We can not guarantee that after fixing the boot sector the drive can be accessed.
The error you're getting after you have selected the partition is a direct result of the fact that we only see the first 128 Gb of the disk while the partition itself is larger.
I have now updated the BIOS on my Epox EP-8K7A+ motherboard & analysed the corrupted partition which now reports no errors & that the chance of recover success (prognosis) is "fair".
I attached the log file for your consideration...
.../000:08/LOG> ### LOG START ###
.../000:08/LOG> DISKPATCH 2.1.100
.../000:08/LOG> (C) 2000-2005, DIY DataRecovery
.../000:08/LOG> Contact info: HTTP://www.DIYDataRecovery.nl
.../000:08/LOG> DPRunType: 0
.../000:08/LOG> DPUsrName: DEMO
.../000:08/LOG> MemFree: 107Kb
.../000:08/LOG> LogDate: 03-15-2005
.../000:08/CFG> Dump Options requested
.../000:08/CFG> FilePath="1/.DP_FILES"
.../000:08/CFG> LogFilename="DP.LOG"
.../000:08/CFG> ReadRetries="32"
.../000:08/CFG> MaxReadErrors="32"
.../000:08/CFG> ReadDelay="1"
.../000:08/CFG> AutoSaveState="1"
.../000:08/CFG> DumpFoundSectors="0"
.../000:08/CFG> LogLevel="2"
.../000:08/CFG> DebugLevel="0"
.../000:08/CFG> MaxFatScan="51200"
.../000:08/CFG> MaxDataColEntries="512"
.../000:08/CFG> ScanType="0"
.../000:08/CFG> IgnoreF8FF="0"
.../000:08/CFG> ScanSignature="55AA"
.../000:08/13H> Ext13H installed test requested
.../000:08/13H> Disk found at 128
.../000:08/13H> Ext13H version: 2.1 / EDD-1.1
.../000:08/13H> Ext13H Support: Extended disk access functions
.../000:09/13H> Ext13H Support: Enhanced disk drive functions
.../000:09/13H> Ext13H Flags: Cylinder/head/sector info is valid
.../000:09/13H> Disk 128 X13H data : 13328/15/63 12594960/512
.../000:09/13H> Disk found at 129
.../000:09/13H> Ext13H version: 2.1 / EDD-1.1
.../000:09/13H> Ext13H Support: Extended disk access functions
.../000:09/13H> Ext13H Support: Enhanced disk drive functions
.../000:09/13H> Ext13H Flags: Cylinder/head/sector info is valid
.../000:09/13H> Disk 129 X13H data : 65535/16/255 390721968/512
.../000:09/13H> Disk found at 130
.../000:09/13H> Ext13H version: 2.1 / EDD-1.1
.../000:09/13H> Ext13H Support: Extended disk access functions
.../000:09/13H> Ext13H Support: Enhanced disk drive functions
.../000:09/13H> Ext13H Flags: Cylinder/head/sector info is valid
.../000:09/13H> Disk 130 X13H data : 65535/16/255 390721968/512
.../000:09/13H> Ext13H tested ok
.../000:09/FDL> DiskList requested
.../000:09/FDL> Disk found at 128
.../000:09/FDL> Disk found at 129
.../000:09/FDL> Disk found at 130
.../000:09/LOG> Dump DiskList requested
### DISKLIST.ARRAY ###
__D_|________LBA_|___H_|__S_|__GB
128 | ..12594960 | 255 | 63 | ..6
129 | .390721968 | 255 | 63 | 186
130 | .390721968 | 255 | 63 | 186
..0 | .........0 | ..0 | .0 | ..0
- Will I be able to access this partition after DiskPatch carries out the necessary repairs?
- Will all the data be intact as it was before the corruption occurred?
Thanks you kindly for all your efforts/advice.
Product you are using: DiskPatch 2.1
Operating system / Service Pack: Windows 2000 (SP4)
Well, now we actaully see components for this partition that we didn't detect before. During the first scan, for example no boot sector was found (even though that sector does reside within the first 128 Gb).
The analysis ate the end of the logfile shows that an NTFS partition is present, and that all seems well for this partition as fat as it concerns the partition table and the boot sector. In other words, all seems fine.
If you can confirm that the expected volume label for this partition is "WD200G" then DiskPatch even was able to find the $MFT at the expected location.
Running a repair with DiskPatch will not have any added value in this case.
What Windows version are you running, and are any service packs installed?
If you download NTFS4DOS from www.datapol.de, are you able to mount and access the partition with that?
I am pretty sure I have already tried NTFS4DOS to no avail, but I will try again to make sure.
I am running Windows 2000 SP4 which identifies the file system as "Unknown" and 0 bytes. I have tried the hard drive in my other PC which is running Windows XP SP2 and recognises the file system as "RAW" and 0 bytes.
So I assume there must be partition table corruption somewhere. Pre-empting that NTFS4DOS may prove unhelpful, what would be my next step to being able to access my drive please?
The EnableBigLba registry key was already added and is set to "1", in the location HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesatapiParameters. (This makes sense because I now remember when I installed the Western Digital hard drive diagnostics, I was asked to enable large hard drive support and I did).
I created a Windows 98SE boot disk with NTFS4DOS, booted to NTFS4DOS which only recognised 3 partitions, but NOT the corrupted partition. Furthermore, when I executed CHKDSKG I got the following:
C: Disk1/Partition1 6142.8MB FS: Windows NT NTFS
?: Disk2/Partition1 190779.705MB FS: Windows NT NTFS (greyed out!)
E: Disk3/Partition1 130002.543MB FS: Windows NT NTFS
G: Disk3/Partition2 60777.162MB FS: Windows NT NTFS
So, NTFS4DOS does see the corrupted partiton but cannot assign a drive letter to it!
I then executed DFGRNTFS and got:
C: Disk1/Partition1 6142.8MB FS: Windows NT NTFS
D: Disk2/Partition1 190779.705MB FS: Windows NT NTFS
E: Disk3/Partition1 130002.543MB FS: Windows NT NTFS
G: Disk3/Partition2 60777.162MB FS: Windows NT NTFS
The corrupted partition (D: above) is not greyed out this time so I pressed D on the keyboard to defragment this partiton but I got the error:
"Error: Volume D: is not NTFS volume"
I booted back into Windows 2000 SP4 and still get the infamous error "the file or directory is corrupted and unreadable" when I try to access the corrupted partition.
There must be some way to repair the corrupted partition table(s). Any more ideas please, please, please?
Product you are using: DiskPatch 2.1
Operating system / Service Pack: Windows 2000 (SP4)
From a DiskPatch point of view nothing can be fixed; all structures that diskpatch examines (and fixes) are okay. That leaves the filesystem itself as the most likely problem, in which case the best way to go is to use a filerecovery tool like iRecover to copy the files from the corrupted partition. When you've done that reformat the disk and verify that it works okay before putting precious data on it again. The iRecover demo allows you to recover 1 folder, so you can determine beforehand if iRecover will be able to help you.
Regards,
Tom
Disgruntled
Mar 17, 2005 - 11:14AM
Re: "End Past EOD" error
Thanks for the reply, Tom.
Data recovery is my last resort because it is hit and miss, so I was kinda hoping you could suggest how I can recovery the partition table, so I can access the whole drive, copy data elsewhere then re-format the drive.
I was hoping DiskPatch was partition table recovery software. I have since been advised to try Partition Table Doctor (http://www.ptdd.com/). Do you have any experience of this or other similar partition table recovery software that may help my situation please?
You're missing the point ... DiskPatch *IS* partition table and boot sector recovery/repair software, and indeed *if* data can not be accessed due to problems in those areas, it can be accessed after those areas were repaired.
The point is, that there are *no errors* in the partition tables or boot sectors. The problem is somewhere else.
A car may not start because the battery is depleted. When the car doesn't start even though the battery is full of live, then charging the battery will not help to get the car started.
Hi Joep, thank you again for your prompt reply. I was a little confused, but now I see from your response that my problem is NOT partition corruption but File System corruption.
Therefore, are there any software packages that repair corrupt File Systems please? (in my case NTFS)?
Repairing filesystem structures is dodgy business. The best thing to do is to copy the files from the damaged partition (and thus not changing the contents/not making the situation worse). As stated earlier, iRecover might be able to help. Use the demo to recover 1 folder and see if the files come out okay.
Regards,
Tom
Disgruntled
Mar 17, 2005 - 2:24PM
Re: "End Past EOD" error
Thank you Tom. I will try iRecover again, but I am pretty sure it will not recovery everything I need and with their correct/recognisable folders and filenames.
I have previously tried file recovery software. Ontrack's EasyRecovery was the best. It performed a RAW Recovery which recovered upto 200 extension file types (e.g. AVI, PDF, etc..) but was missing obvious file types like MPG, MPEG, RAR, R01, R02, R03, etc... I am still learning how to use WinHex (www.winhex.com) to create a signature file for each extension that I want the RAW Recovery to search/recover for but is proving difficult. I need to know the 8-digit hexadecimal and offset to create a signature. I have never used a hexadecimal editor like WinHex before so any help would be greatly appreciated.
Also, I am curious/confused again... I thought a corrupt partition table(s) was part of the NTFS File System, therefore one of the same thing. Are they not?
"I will try iRecover again, but I am pretty sure it will not recovery everything I need and with their correct/recognisable folders and filenames."
Yes, you can only find out by trying. BTW it is very rare that on an NTFS volume no filenames at all are found. If no file names are found at all it would mean that each and every sector that made up the MFT was corrupted.
"I am still learning how to use WinHex (www.winhex.com) to create a signature file for each extension that I want the RAW Recovery to search/recover for but is proving difficult."
Yes, and it is not possible for all file types. The file must have a recognizable header, so for each file type you must examine a few files. Also, the method will almost always result in a fair share of 'false positives'.
For many of the file types with a recognizable header you'll oftenfind that the first few bytes will do the trick. I that case offset is 0 (zero).
If you find that for a given file type that:
file 1: 0e ee 6e ef 44
file 2: 1e aa 6e ef 44
then 3 bytes at offset 2 seem to be a sequence that both files have in common. You'd add that as a signature. So determine the offset you count zero based. First byte is zero, second 1 etc.
Hope that explains a little about that ...
"I thought a corrupt partition table(s) was part of the NTFS File System"
No, partition tables are not part of the NTFS or any file system. Partition tables are outside partitions and they basically point to areas on the disk that contain a file system. The first component that is file system specific is the boot sector. The boot sector of a partition could be regarded the starting poit of the file system structures within a partition. For example, a FAT boot sector points to the main structure; the FAT. While an NTFS boot sector points to the MFT.
You can repair a boot sector (maybe) if it is corrupt, but that wouldn't help a lot if other file system components like the MFT are corrupt.
In your case, the partition tables are fine, and the boot sector looks very valid as well. So something is wrong further down the chain.
The MFT is a very complex structure, trying to fix it is very risky and very time consuming. One MFT entry (describing a single file) consists of multipe, and dynamic attributes.
I am quite sure I have corrupted $MFT because when I try to open the drive I get a "corrupted $MFT" error message.
I am desperate to access this drive so I am prepared to dedicate the time and take the risk. So please reply with all your suggestions on how I can repair the MFT(s) please.
Oh my, I shouldn't have said that :-). What you want can not be done.
First of all, this is primarely a support forum for the DIY DataRecovery products. We believe that supporting demo products that are not payed for is the right thing to do. There are limits however. Our knowledge on disk structures is the result of 1000's of hours of self study, tinkering, and a lot of trial and error. This knowledge we make available in the form of support and software. So far, there's at least 45 minutes of our time spent on helping you and answering your questions while you haven't payed a dime yet. Now that's not a problem as I explained before, but, no offense intended, you can not expect us to now lecture you on a complex file system as NTFS. You can help yourself though, this is the best public resource on NTFS to be found on the net: http://linux-ntfs.sourceforge.net/ntfs/.
Second, you have already discovered that tools you have tried to recover the data with have the greatest trouble trying to figuring out the drive structure. Before you can repair a drive structure, you have to figure it out, you have to discover what's still intact, what's missing and find puzzle pieces that can help you reconstructing the missing structures. If There's insufficient data to figure it out, you can not fix it. The fact that the data recovery tools can not figure it out, is a good indication too much is missing and there are no pieces that can help reconstruct this missing info.
Hi Joep, I really do appreciate your time and effort (and Tom's) in helping me in my time of crisis. I work in IT & spend most of my days helping other people, so in this rare occasion that I need help, I thank you both greatly. Also, thank you for the NTFS link! I will investigate further.
While I ran iRecover in Automatic Mode, at the bottom of the screen it displayed "Filesystem type is: Not known so far". So iRecover could not identify the corrupted partition as NTFS. However, when Analysing Stage 3 (approx. 70%) - Searching for FATs - "Filesystem type is: FAT". Strange how iRecover identified the filesystem as FAT instead of NTFS(?).
Once the scan had finished, I got a long list of folders beginning with FRG:
I selected to recover the top folder FRG00013, selected a folder to save to, clicked Proceed & this was displayed on screen:
Filesystem Type FAT
Total files selected 1
Both FATs good 0
1st FAT good 0
2 FAT good 0
Both FATs bad 1
I then clicked Next, opened the folder I saved the recovery to and it is blank! So the data recovery failed. I can only assume this is because it cannot determine the filesystem correctly.
Am I doing something wrong? Should I alter the options in iRecover before I do a full scan/recovery? Will iRecover be able to recover any file types, like Ontrack's EasyRecovery can?
Best Regards
Product you are using: DiskPatch 2.1
Operating system / Service Pack: Windows 2000 (SP4)
"While I ran iRecover in Automatic Mode, at the bottom of the screen it displayed "Filesystem type is: Not known so far". So iRecover could not identify the corrupted partition as NTFS. However, when Analysing Stage 3 (approx. 70%) - Searching for FATs - "Filesystem type is: FAT". Strange how iRecover identified the filesystem as FAT instead of NTFS(?)."
No, it is not strange. Again, for a human or software to be able to tell what file system may have been present in a certain area on the disk, something must be left that allows you recognize what was there.
Appearantly, there isn't much left at all. Anyway, I'd run iRecover again specify that the file system you expect is NTFS. Just to make sure and check if it does recover more.
Now again. All points to severely damaged system structures. None of the tools you have tried can find any filenames and this probably means the file names are lost! If they are not there you can not recover them.
Doing what you were already doing (scanning for file sigantures) is the only thing left to try.
Without wanting to be unfriendly: I consider this discussion closed.
Board
"End Past EOD" error
bravenet.com