| Author | Message | ||
     Roy Zider |
Hi: I've identifed several bad sectors on a disk. How do I use WinHex to find out what file(s) contain these sectors? TIA -- Roy | ||
| Stefan Fleischmann (Admin) |
1) You open the logical drive in WinHex. Hopefully the cluster scan ("Traversing cluster chains...") can complete without error. 2) You go to one of the bad sectors (Position | Go To Sector). A read error will occur. You reply "Yes, ignore always". 3) If 1) was successful, the details panel will reveal the allocation of the cluster that this sector belongs to. | ||
| Roy Zider |
Stefan: Further to my earlier reply to your note, I did as you are suggesting and opened the logical drive (T  . At the moment it is hung at 57% scan of "Traversing cluster chains". Or it was, before I switched away from WinHex. Now Task Manager can't switch back, as it shows WinHex "Not Responding" for at least the last five minutes. Isn't there some sort of a timeout for WinHex when it hits a bad sector? OK -- after 10 minutes or so I just got an Error #6 message: "An error occurred while reading from Sector 130,343,878 of Drive T: the request could not be performed because of an I/O device error." How should I proceed? -- Roy Zider Windows 2K SP 3 Tyan dual CPU MPX, 5-10% CPU utilization 200GB ATA drive, single partition NTFS | ||
| Stefan Fleischmann (Admin) |
Will e-mail you a possible solution. | ||
| Roy Zider |
Stefan: OK, now having gotten past a couple of sectors found bad, I'm at "Error #3: An error occurred while writing "c:\docume~1\r08c6~.zid\locals~1\temp\Drive D879E1E9 Clusters.dir". Make sure the folder exists and the file is not write protected." Checking this directory structure, I find the directory "r08c6~~zid", not "r08c6~.zid". Tried to rename it in Windows Explorer, but couldn’t (“a file with the name you specified already exists. Specify a different file name.” So after several attempts, I deleted the whole tree and created “C:\Documents and Settings\R08C6~.ZID\LOCALS~\TEMP”. Then I pressed the “OK” key on the WinHex error message. (Note that I made an error here – the intermediate directory should have been “LOCALS~1”, not “LOCALS~”.) After that, WinHex returned to its normal hex display of the T: drive. Checking for this file of clusters.dir, I found it at C:\Documents and Settings\R. Zider\Local Settings\Temp. Drive D879E1E9 Clusters.dir 0 KB Drive D879E1E9 Files.dir 342 KB I then deleted the tree C:\Documents and Settings\R08C6~.ZID\LOCALS~\TEMP”. Then using Tools | Disk Tools | Re-scan cluster chains I re-scanned cluster chains. At 57% I again encountered two Error #6 errors, for the below sectors ( I selected “No” to ignore this error only): 130,343,878 130,343,879 Then I got the Error #3 reported above. This time there was no directory at all with ..\R08C6~.ZID\LOCALS~\TEMP. I pressed OK and WinHex was done again. The Clusters.dir and …Files.dir files were in C:\Documents and Settings\R. Zider\Local Settings\Temp, as found earlier, this time with a timestamp reflecting the recent run. In order to try to clear this directory error, I then created the tree C:\Documents and Settings\r08c6~.zid\locals~1\temp and re-ran WinHex. Now it hung for a couple of hours at 57% -- had to reboot the machine. Hope these comments are helpful to you. -- Roy Zider Using WinHex 11.0 SR4 Windows 2K SP4 NTFS 200GB WD2000JB drive NTFS single partition Tyan MPX dual Athlon 2000+ CPU motherboard 512MB registered ECC SDRAM | ||
| Stefan Fleischmann (Admin) |
You could specify a folder for temporary files more straight-forward than the one deeply nested in your Windows profile in the General Options dialog in WinHex. There should be no need to cope with the temp folder path. Maybe the files in that folder were still locked (and thus could not be re-written) because you had to terminate a previous instance of WinHex in an unclean way. Considering the unpredictable hangs when WinHex encounters bad sectors I actually cannot recommend you proceed like this on that disk. The possibility I described by e-mail might be feasible, and much more efficient. | ||
| Roy Zider |
Stefan: 1) The temp folder is generated by W2K -- and as you suggest, it may have been locked because of an earlier lockup by WinHex that required a hard reset of the system (an "unclean" termination). 2) I don't intend to use this disk -- I just want to get the files off it. The diagnostic query was to determine before hand what files I could expect to give me problems. Windows Explorer will choke when it encounters it. There are maybe 30,000 files involved here. I want to get them off this HDD as soon as possible, identify the ones that are corrupted, and find the backup for them if it exists. With the suggestion of using nfi.exe, I can identify the problem file(s) given a physical LBA sector. What remains outstanding now, if you want to say that, is why WinHex hangs the system and what, if anything, I can do about it. Hope this is helpful -- thanks for your excellent response. -- Roy Zider | ||
| Stefan Fleischmann (Admin) |
Sorry, I don't think there is a way to prevent the operating system from hanging WinHex. | ||
| Mike Montgomery (Mikem22) |
Yes, Stephan is correct. Windows system does not use direct ATA port access but uses Hardware Abstraction Layers (HAL). Sometimes when a drive hangs due to a bad sector, a soft reset command sent to the port can reset the Status and Error ATA registers of the drive to return it to 'Ready' mode. .. Sometimes the drive itself hangs because its internal firmware can not cope with the type of error generated and will need a hard reset to re-initialise. You could look at BusHound as this monitors and can trap the ATA commands sent to the drive and reads the registers using HAL. It is also possible to send commands through Bushound to the drive so sending a soft reset may help the process. Bushound also works on all other ports inc SCSI, USB, SERIAL, PARALLEL, etc.. Mike | ||
| Roy Zider |
Mike: Yes, thanks for the reminder about the HAL vs. direct ATA port access. I was aware of this, but was only suggesting that the program launch a separate thread to access the drive, and then monitor that thread for a good return, an error return or a timeout. As it stands, going single-threaded into what may probably be a bad disk doesn't seem to me to be the right way to design this part of the program. Bushound sounds like the right sort of drive monitor. Roy | ||
| Stefan Fleischmann Username: admin Registered: 1-2001 |
Just remembered this discussion. On June 2, 2005 WinHex 12.25 was released and introduced the user-defined time-out for an alternative disk access method (General Options). |