awnews Posted January 30, 2003 Report Share Posted January 30, 2003 I was wondering if anybody had any insight into the situation I describe below. I recently upgraded a system from Windows 2000 Pro to XP Pro (rare. I usually do clean installs). After I did so, I started seeing some odd messages in the Retrospect Pro 6 (Dantz's backup program) log, stating that there was a Windows problem with an "oembios.bin" file. + Normal backup using SWPC2_Full_Server at 1/30/2003 1:43 AM To Backup Set SWPC2_Full_Server... - 1/30/2003 1:43:51 AM: Copying DRIVE_C (C:) MapError: unknown Windows error 23 can't read data, BackupRead failed, C:\WINNT\system32\dllcache\oembios.bin, winerr 23, error -1001 File "C:\WINNT\system32\dllcache\oembios.bin": can't read, error -1001 (unknown Windows OS error) 1/30/2003 1:49:42 AM: Snapshot stored, 47.5 MB The "C:\WINNT\system32\dllcache\oembios.bin" directory and file doesn't exist. A look at the disk shows that the only "oembios.bin" file is not where Retrospect is reporting it to be in the log. C:\WINNT\system32 ==> oembios.bin does exist And the only "dllcache" directory is also not where Retrospect is reporting it to be. And that directory is empty. C:\WINNT\LastGood.Tmp\System32\dllcache is empty Other than that, the RP6 backups seem to be working OK. I also noticed that the Windows Event Viewer (System) was reporting bad blocks after each scheduled start & run of Retrospect (but at no other time or with any other programs). I tried to image the drive. Running DriveImage 2002 failed with a CRC error. Running Norton Ghost 2003 also failed (mentioning the "oembios.bin" file) until I turned on the -fro (force, to ignore source errors) and then I was able to make an image. So these programs confirm that there is a disk issue. I ran Norton Utilities and CHKDISK (in "DOS" mode on boot) and neither reported any problems. Window XP's System Restore is off. All drives (C: source where the problem seems to be, and the destination backup drive) are NTFS. NTFS is supposed to be "self-healing" in the case of most new bad blocks (note: most harddisks have bad blocks that are mapped out. In the drive controller, statically, dynamically, during a format??). And indeed the OS and most other programs don't seem to be having any problems. I could of course do a full reformat and reinstall (OS, programs, data) but I'm trying to avoid going to all that effort. I have heard some anecdotal accounts of similar problems being corrected by doing a defragment and I have a good program for that (PerfectDisk) but I'm trying to hold off doing that (may not be needed. may want to replace the drive rather than just reformat it). Link to comment Share on other sites More sharing options...
JohnA Posted January 31, 2003 Report Share Posted January 31, 2003 Hi, I wonder it it's the case that the file system operation is completing sucessfully but a warning is being generated by Windows that the block was imperfect which Retrospect is interpreting as an error. If true, I wonder if there's a problem backing up to DVD-RAM drives too which rely on the OS to write the data - means the media has to be perfect. I am interested also with any comments that might develop here. Sincerely, John Link to comment Share on other sites More sharing options...
awnews Posted February 1, 2003 Author Report Share Posted February 1, 2003 My "bad blocks" problem has been fixed, thanks to a suggestion from tech support at Raxco Software, makers of PerfectDisk (disk defragger for windows). In summary, even though I had already run "CHKDSK" (/f) on the PC, the normal CHKDSK doesn't check or repair everything, including bad blocks. To do that, you need to specify additional command line options, in this case /r (CHKDSK /f /r). So I did that and then let RP6 run its next scheduled backup. The RP6 log no shows the "MapError: unknown Windows error 23 can't read data, BackupRead failed" message and the Windows Event Viewer (System) no longer reports "bad blocks" while RP6 is running. I'll still keep an eye on things to make sure this is a one-time thing (a few [new?] bad blocks) vs. an indication of pending drive failure (more bad blocks keep appearing). Regarding this and DVD-RAM drives, I don't know if the problem and solution are applicable. I don't know if CHKDSK can be run on a DVD-RAM and. And even if it could, I don't know if DVD-RAMs have the same formatting structure, including the $BadClus file, to report bad sectors. I've included some more details below to wrap this up in case others are interested. ----------------------- Good morning and thanks for contacting Raxco Software Support! A little background on defragmenting (in case you don't already know)... Defragmenters don't actually "move" files. Microsoft provides as part of the operating system a set of Win32 API calls that anybody can use to "move" a file. Defragmenters use these defrag "APIs" to request that a file be moved from one set of logical clusters to another set of logical clusters. It is the file system itself that actually performs the file "move" - returning control back to the defragmenter when finished (with a success or failure status). When "moving" a file, the file system performs both read and write verification of clusters. It verifies that the original clusters can be read and that the target clusters are indeed free and can be written to. If the read verification fails, the file "move" fails. If the write verification fails, CHKDSK is immediately scheduled to run on next boot and an entry is made in the System event log and you may see pop up boxes saying that the file/directory is possibly corrupt. Of course, in this event, the file "move" also fails. The CHKDSK that is performed at boot time isn't a complete CHKDSK. I would suggest that you do a CHKDSK /F /R on the drive. This will do a complete scan of the file system and should update the bad cluster ($BadClus) file - so that the file system recognizes the clusters as bad. ----------------------- I had heard some anecdotal accounts of bad block problems being fixed by running disk defraggers. But based on my experience and the comments for Raxco, I suspect the real reason is that a failed defrag results in the automatic running of "CHKDSK /f /r" which repairs the bad block problem. ----------------------- CHKDSK Creates and displays a status report for a disk based on the file system. Chkdsk also lists and corrects errors on the disk. Used without parameters, chkdsk displays the status of the disk in the current drive. Syntax chkdsk [volume:][[Path] FileName] [/f] [/v] [/r] [/x] [/c] [/l[:size]] /f Fixes errors on the disk. The disk must be locked. If chkdsk cannot lock the drive, a message appears that asks you if you want to check the drive the next time you restart the computer. /r Locates bad sectors and recovers readable information. The disk must be locked. ----------------------- NTFS includes several system files, all of which are hidden from view on the NTFS volume. A system file is one used by the file system to store its metadata and to implement the file system. System files are placed on the volume by the Format utility. $BadClus file – records any bad clusters on the volume so that Windows NT/(2000/XP) will not write to that disk region in the future. Link to comment Share on other sites More sharing options...
JohnA Posted February 1, 2003 Report Share Posted February 1, 2003 >> Regarding this and DVD-RAM drives, I don't know if the problem and solution are applicable. I don't know if CHKDSK can be run on a DVD-RAM and. And even if it could, I don't know if DVD-RAMs have the same formatting structure, including the $BadClus file, to report bad sectors. << Well, that makes both of us who don't know, but thanks very much for the information and the time you took to post it, I really appreciate it. Unfortunately, I cannot get Retrospect to work properly with my system backing to DVD-RAM, so I am going back to another solution which doesn't seem to have problems backing up and verifying. Take care, John Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.