Quirks in Scandisk, Chkdsk, Fixmbr, Fixboot

[Franc Zabkar]

I recently had to repair file system corruption for two XP users, one
with a FAT32 partition, the other with NTFS. Unfortunately I have
little experience with XP so I struggled quite a bit. Anyway I
discovered that Microsoft's disc repair tools were flawed in several
ways.

Case #1
-------

The PC with the NTFS partition had an inaccessible registry file,
c:\windows\system32\config\system. It couldn't be deleted, copied, or
renamed, so the procedure in this MSKB article could not be applied:

How to recover from a corrupted registry that prevents Windows XP from
starting:
http://support.microsoft.com/kb/307545

I attempted to run CHKDSK from the repair console of a bootable XP CD,
but the file system was deemed to have unrecoverable errors. I then
installed the drive into an external USB enclosure, attached it to a
working XP system, and ran CHKDSK from within a CMD window. CHKDSK
found many problems, including an MFT issue, all of which were fixed.
Prior to running CHKDSK, I tried to repair the drive from within the
GUI via Tools > Properties, but this also produced an "unrecoverable"
message.

Case #2
-------

The PC with the FAT32 partition could not boot. It produced a "missing
NTLDR" error. This suggested that the MBR and boot sector were
probably OK, and that the error was somewhere in the FATs or directory
structure. I booted into the repair console of an XP CD and tried a
DIR command. This produced a "could not be enumerated" error. DISKPART
was able to see the full partition (38GB), so the partition table and
MBR were apparently OK. CHKDSK deemed that the drive was
"unrecoverable". In desperation I tried the FIXBOOT command and that's
when things became extremely bizarre. A DIR command was now able to
see the C: drive, but there were no files! The partition size was
reported as 10MB (or was it 10GB?). I reconfirmed with DISKPART that
the partition table was still intact, but in desperation I now tried
FIXMBR. This command warned me that the MBR contained unknown or
damaged code, so I went ahead and allowed it to refresh the code. It
reported success but when I ran FIXMBR a second time, it still
complained of unknown or damaged code.

Now I'd had enough, so I installed the drive into an external USB
enclosure and attached it to a working XP system. I used DEBUG from
with a CMD window to view the drive's boot sector and was horrified to
see a FAT12 signature. For some inexplicable reason, FIXBOOT had
replaced a FAT32 HD boot sector with a FAT12 floppy boot sector!
CHKDSK was unable to repair this problem, and My Computer showed the
drive as having a capacity of 10MB (or 10GB?). I then used DEBUG to
zero the contents of the boot sector, thinking that now CHKDSK would
have a better chance to repair it, but CHKDSK now complained that it
would not operate on a RAW volume. Attempting to repair the drive from
within the GUI using Tools > Options produced no response.

Now I was getting desperate. I took the USB drive to my Windows 98SE
box and to my surprise Explorer was able to see the entire drive with
all the original files apparently still intact! SCANDISK determined
that the first copy of the FAT was corrupt, but it didn't tell me that
the boot sector was missing. It just used the backup copy of the boot
sector (logical sector 6) and behaved as if all was well. With some
trepidation I allowed Scandisk to repair the FAT, and to fix the
misreported file sizes for SYSTEM.LOG and SOFTWARE.LOG. However,
Scandisk did not replace the damaged boot sector. I had to do this
manually via DEBUG in a DOS box, by copying the contents of sector 6
to sector 0. After doing this, I was able to see the all the files in
a working XP system (in the USB enclosure), and CHKDSK reported that
all was fine. However, I was still unable to boot from the drive when
I reinstalled it in the original XP box.

So what was wrong? I looked closely at the boot sector again and found
that it was a Win9x boot sector, ie there were references to IO.SYS,
MSDOS.SYS and WINBOOT.SYS, but no reference to NTLDR. WTF! I decided
to load XP onto a spare HD that had been FDISKed and FORMATted by
Windows 98SE and sure enough XP replaced the boot sector with its own
FAT32 code, but it did not touch the backup boot sector. So XP had
created a file system that had an XP boot sector and a Win9X backup.

So what to do now? I decided to make a hybrid boot sector by using the
tail end of an XP FAT32 boot sector for the code, and the beginning of
the Win9X boot sector for the data. After restoring this patched boot
sector to sector 0, the drive booted in the original machine and all
was well. BTW, boot sector templates can also be extracted from
AUTOCHK.EXE.

As a final check, I used MBRtool to make a copy of the MBR code. I
then compared this with an MBR template that I found inside
DISKPART.EXE. There was no difference. So why did FIXMBR complain
about unknown or damaged code?

- Franc Zabkar

 

[PD43]

I recently had to repair file system corruption for two XP users, one
with a FAT32 partition, the other with NTFS. Unfortunately I have
little experience with XP so I struggled quite a bit. Anyway I
discovered that Microsoft's disc repair tools were flawed in several
ways.

[snip of a lotta crapola]

You're in luck: XP has been replaced by VISTA.

Go for it.

 

[sgopus]

Too much for your feeble brain??

 

[MEB]

| I recently had to repair file system corruption for two XP users, one
| with a FAT32 partition, the other with NTFS. Unfortunately I have
| little experience with XP so I struggled quite a bit. Anyway I
| discovered that Microsoft's disc repair tools were flawed in several
| ways.
|
| Case #1
| -------
|
| The PC with the NTFS partition had an inaccessible registry file,
| c:\windows\system32\config\system. It couldn't be deleted, copied, or
| renamed, so the procedure in this MSKB article could not be applied:
|
| How to recover from a corrupted registry that prevents Windows XP from
| starting:
| http://support.microsoft.com/kb/307545
|
| I attempted to run CHKDSK from the repair console of a bootable XP CD,
| but the file system was deemed to have unrecoverable errors. I then
| installed the drive into an external USB enclosure, attached it to a
| working XP system, and ran CHKDSK from within a CMD window. CHKDSK
| found many problems, including an MFT issue, all of which were fixed.
| Prior to running CHKDSK, I tried to repair the drive from within the
| GUI via Tools > Properties, but this also produced an "unrecoverable"
| message.

That error seems to indicate corruption within the streams and other file
handling. Did the computer get rapidly shut off by power disruption, or
perhaps suffered power flucuations?

http://support.microsoft.com/kb/308041
Resources for troubleshooting startup problems in Windows XP
http://support.microsoft.com/kb/307654
How to install and use the Recovery Console in Windows XP
http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c28621675.mspx
XP Professional Resource Kit - Troubleshooting Disks and File Systems

Excerpt http://support.microsoft.com/kb/314835/en-us:
If you run CHKDSK online, the code that actually performs the verification
resides in utility DLLs, for example Untfs.dll and Ufat.dll. The
verification routines that CHKDSK invokes are the same routines that run
when a volume is verified through the Windows Explorer or Disk Management
graphical user interface.
However, if CHKDSK is scheduled to run when the computer restarts, the
binary module that contains the verification code is Autochk.exe, a native
Windows program. Because Autochk.exe runs early in the computer's startup
sequence, Autochk.exe does not have the benefit of virtual memory or of
other Win32 services.
Autochk.exe generates the same kind of text output that the Chkdsk.exe
utility DLLs generate.

NOTE where the information is obtained from/used.

Microsoft Windows 2000 uses the NTFS file system version 3.0, and Windows
XP uses the NTFS file system version 3.1.
The MBR created by a running Windows 2000 or XP OS (specifically Disk
Management) when used to install a completely blank hard drive on your
system; includes details about the Win 2k/XP *Disk Signature bytes*!
http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm
http://thestarman.pcministry.com/asm/mbr/NTLDR.htm
http://thestarman.pcministry.com/asm/mbr/ntFAT32BR.htm

| Case #2
| -------
|
| The PC with the FAT32 partition could not boot. It produced a "missing
| NTLDR" error. This suggested that the MBR and boot sector were
| probably OK, and that the error was somewhere in the FATs or directory
| structure. I booted into the repair console of an XP CD and tried a
| DIR command. This produced a "could not be enumerated" error. DISKPART
| was able to see the full partition (38GB), so the partition table and
| MBR were apparently OK. CHKDSK deemed that the drive was
| "unrecoverable". In desperation I tried the FIXBOOT command and that's
| when things became extremely bizarre. A DIR command was now able to
| see the C: drive, but there were no files! The partition size was
| reported as 10MB (or was it 10GB?). I reconfirmed with DISKPART that
| the partition table was still intact, but in desperation I now tried
| FIXMBR. This command warned me that the MBR contained unknown or
| damaged code, so I went ahead and allowed it to refresh the code. It
| reported success but when I ran FIXMBR a second time, it still
| complained of unknown or damaged code.

First I would question whether you cold rebooted between the two FIXMBR
[FIXMBR {ugh} which I found to be questionable when using] trys.

Second:
http://support.microsoft.com/kb/300415/ - Diskpart Command-Line Utility

Third, did you use the proper commandline syntax for the tools?

http://support.microsoft.com/kb/247575/EN-US
Chkdsk Does Not Use Backup Boot Sector to Fix Corrupted FAT32 Boot Sector

http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/z03c621675.mspx
XP Professional Resource Kit - Tools for Troubleshooting

|
| Now I'd had enough, so I installed the drive into an external USB
| enclosure and attached it to a working XP system. I used DEBUG from
| with a CMD window to view the drive's boot sector and was horrified to
| see a FAT12 signature. For some inexplicable reason, FIXBOOT had
| replaced a FAT32 HD boot sector with a FAT12 floppy boot sector!
| CHKDSK was unable to repair this problem, and My Computer showed the
| drive as having a capacity of 10MB (or 10GB?). I then used DEBUG to
| zero the contents of the boot sector, thinking that now CHKDSK would
| have a better chance to repair it, but CHKDSK now complained that it
| would not operate on a RAW volume. Attempting to repair the drive from
| within the GUI using Tools > Options produced no response.

Yeah CHKDSK would complain ALOT about that, it had nothing to work with.

|
| Now I was getting desperate. I took the USB drive to my Windows 98SE
| box and to my surprise Explorer was able to see the entire drive with
| all the original files apparently still intact! SCANDISK determined
| that the first copy of the FAT was corrupt, but it didn't tell me that
| the boot sector was missing. It just used the backup copy of the boot
| sector (logical sector 6) and behaved as if all was well. With some
| trepidation I allowed Scandisk to repair the FAT, and to fix the
| misreported file sizes for SYSTEM.LOG and SOFTWARE.LOG. However,
| Scandisk did not replace the damaged boot sector. I had to do this
| manually via DEBUG in a DOS box, by copying the contents of sector 6
| to sector 0. After doing this, I was able to see the all the files in
| a working XP system (in the USB enclosure), and CHKDSK reported that
| all was fine. However, I was still unable to boot from the drive when
| I reinstalled it in the original XP box.
|
| So what was wrong? I looked closely at the boot sector again and found
| that it was a Win9x boot sector, ie there were references to IO.SYS,
| MSDOS.SYS and WINBOOT.SYS, but no reference to NTLDR. WTF! I decided
| to load XP onto a spare HD that had been FDISKed and FORMATted by
| Windows 98SE and sure enough XP replaced the boot sector with its own
| FAT32 code, but it did not touch the backup boot sector. So XP had
| created a file system that had an XP boot sector and a Win9X backup.
|
| So what to do now? I decided to make a hybrid boot sector by using the
| tail end of an XP FAT32 boot sector for the code, and the beginning of
| the Win9X boot sector for the data. After restoring this patched boot
| sector to sector 0, the drive booted in the original machine and all
| was well. BTW, boot sector templates can also be extracted from
| AUTOCHK.EXE.

AUTOCHK is apparently the proper code to use.

|
| As a final check, I used MBRtool to make a copy of the MBR code. I
| then compared this with an MBR template that I found inside
| DISKPART.EXE. There was no difference. So why did FIXMBR complain
| about unknown or damaged code?
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

You're dealing with the wonders of Microsoft and NT5.1 there. Another
question would be whether the newest versions of those tools were used.
But I must say that personally, I generally try to use other's tools rather
than Microsoft's..

There are other disk tools which seem to work better/easier with NTFS and
NT5 file systems. Check out Testdisk, HDAT, and MHDD.
http://www.cgsecurity.org/wiki/TestDisk_Download - now at version 6.9
http://hddguru.com/
http://hddguru.com/content/en/software/2005.10.02-MHDD/
http://www.hdat2.com/

BTW Franc, you're part of the reason I posted that link for the non-GUI
Microsoft OS in here. Though you might want to get in on the ground floor of
what will likely translate to the nex-gen/new processor base coding, for
what may be used in the non-legacy Windows. Kinda like the old DOS days and
downloading betas from Microsoft's BBS before it turned into the monster it
is ... (now if only they were paying the beta testers.. hahaha)

 

[none]

Franc, although this post is beyond my technical ability it was read
with wonder. Wish I could answer your question !!

Perhaps you can answer mine:
I own an IBM Thinkpad notebook PC. It seems IBM uses an unusual boot
sector. I've read it is a L-O-N-G sector (greater in size than normal?)
It also seems unless IBM's install routine is used to install an OS you
might as well forget booting. For example, if you formated FAT32 for
Win98 and had applied the SYS command (FORMAT C: /s) the PC would just
throw an error (Operating System not found).

If a bootable HD (IBM) was cloned to a new HD and the boot sector was
also cloned you could boot but obviously IBM's BIOS is looking for more
than the standard boot sector. Would you happen to know anything about
these non-conventional boot sectors? Would you know how to save a
non-conventional boot sector's infomation in the event it was needed to
be reinstalled? I've used MBRtool but am not convinced it saved ALL the
information necessary. I'm thinking it just saved a CONVENTIONAL BS
length. Have not tried applying the saved BS information to another
drive to see if it was bootable however.

Thanks for any help!
Vic

 

[Franc Zabkar]

I own an IBM Thinkpad notebook PC. It seems IBM uses an unusual boot
sector. I've read it is a L-O-N-G sector (greater in size than normal?)
It also seems unless IBM's install routine is used to install an OS you
might as well forget booting. For example, if you formated FAT32 for
Win98 and had applied the SYS command (FORMAT C: /s) the PC would just
throw an error (Operating System not found).

If a bootable HD (IBM) was cloned to a new HD and the boot sector was
also cloned you could boot but obviously IBM's BIOS is looking for more
than the standard boot sector. Would you happen to know anything about
these non-conventional boot sectors? Would you know how to save a
non-conventional boot sector's infomation in the event it was needed to
be reinstalled? I've used MBRtool but am not convinced it saved ALL the
information necessary. I'm thinking it just saved a CONVENTIONAL BS
length. Have not tried applying the saved BS information to another
drive to see if it was bootable however.

Thanks for any help!
Vic

The following diagram (fixed width font) is my understanding of the
structure of a FAT32 volume. Not all disc tools can see all parts of
the physical disc, so I have attempted to show where they can be used
(AIUI).


mbrtool chkdsk, scandisk, debug, sys, format
| |
| |
| |
|track 0 |
| |-- logical drive C: (FAT32) --------------------------|
physical |
sector 0 |
| |
| | Backup mostly
MBR ----- Boot --- boot -- blank -- FAT#1 - FAT#2 - Root --- File
+ sector sector sectors directory area
Partition 0 6
Table
| |
| |
| sys
| fixboot
| format
fdisk
fixmbr
mbrtool

I have no experience with IBM notebooks, but third party boot managers
usually live in track 0, ie just before the first logical volume. They
can occupy several sectors, not just sector 0. You can use MBRtool to
save track 0 and/or physical sector 0. The latter is where the
partition table and MBR code normally reside, although your boot
manager (or virus) may relocate the partition table to another sector.
If the partition table has been relocated, then that may explain why
the hard drive is invisible after booting from a floppy or CD. In this
case it's only after the non-standard MBR code has been executed
during the course of a normal HD boot that the partition table becomes
visible and logical volumes can be found.

If I were trying to understand your file system, I would first look at
track 0, but I would boot from a floppy or CD to do this, otherwise
you couldn't be sure that the MBR code in the HD wasn't masking the
real track 0.

If you want to see the contents of the boot sector of logical drive
C:, then execute the following at the DOS prompt:

debug
-L 100 2 0 1
-D 100 2ff
-Q

To see the backup boot sector, type ...

debug
-L 100 2 6 1
-D 100 2ff
-Q

- Franc Zabkar

 

[... et al.]

I recently had to repair file system corruption for two XP users, one
with a FAT32 partition, the other with NTFS. Unfortunately I have
little experience with XP so I struggled quite a bit. Anyway I
discovered that Microsoft's disc repair tools were flawed in several
ways.


Case #2
-------

The PC with the FAT32 partition could not boot. It produced a "missing
NTLDR" error. This suggested that the MBR and boot sector were
probably OK, and that the error was somewhere in the FATs or directory
structure. I booted into the repair console of an XP CD and tried a
[snip]


Now I was getting desperate. I took the USB drive to my Windows 98SE
box and to my surprise Explorer was able to see the entire drive with
all the original files apparently still intact! SCANDISK determined

Because "I have little experience with XP" .. i don't see that
you mention that the [NTLdr] file ( and the [NTDetect.com] file )
is there or that you tried with a new copy off the WinXP CD in
case of corruption.

[snip]

So what was wrong? I looked closely at the boot sector again and found
that it was a Win9x boot sector, ie there were references to IO.SYS,
MSDOS.SYS and WINBOOT.SYS, but no reference to NTLDR. WTF!

Ok, but since i don't know that there normally is, i mentioned
the above just in case.

 

[Franc Zabkar]

I recently had to repair file system corruption for two XP users, one
with a FAT32 partition, the other with NTFS. Unfortunately I have
little experience with XP so I struggled quite a bit. Anyway I
discovered that Microsoft's disc repair tools were flawed in several
ways.


Case #2
-------

The PC with the FAT32 partition could not boot. It produced a "missing
NTLDR" error. This suggested that the MBR and boot sector were
probably OK, and that the error was somewhere in the FATs or directory
structure. I booted into the repair console of an XP CD and tried a
[snip]


Now I was getting desperate. I took the USB drive to my Windows 98SE
box and to my surprise Explorer was able to see the entire drive with
all the original files apparently still intact! SCANDISK determined

Because "I have little experience with XP" .. i don't see that
you mention that the [NTLdr] file ( and the [NTDetect.com] file )
is there or that you tried with a new copy off the WinXP CD in
case of corruption.

A DIR from within the XP repair console produced some kind of "could
not enumerate" error, so I couldn't see any files at all. CHKDSK was
unable to recover the file system. In desperation I tried a FIXBOOT,
hoping that it would work much like SYS.COM in a Win9x machine. That
is, I was hoping that FIXBOOT would fix the boot files, eg NTLDR and
whatever else was required. Instead, AFAICT, FIXBOOT just trashed the
boot sector. :-(

BTW, I had no software tools with me at this time, only an XP CD.

[snip]

So what was wrong? I looked closely at the boot sector again and found
that it was a Win9x boot sector, ie there were references to IO.SYS,
MSDOS.SYS and WINBOOT.SYS, but no reference to NTLDR. WTF!

Ok, but since i don't know that there normally is, i mentioned
the above just in case.

AFAICT, the original problem was damage to the first copy of the FAT.
This was repaired by Scandisk. Both NTxxx files were intact. In a
Win98 box I was able to see the NTxxx files as well as autoexec.bat
and config.sys. The last two files had sizes of 0. IIRC io.sys and
msdos.sys were also there, and both also had file sizes of 0.

After I had the drive booting in the original machine, I ran Seagate's
SeaTools for DOS hard disc diagnostic. It found 6 bad sectors which it
was able to repair. A subsequent check with SmartUDM reported 56
reallocated sectors, suggesting that the drive may be on its way out.

See http://www.users.on.net/~fzabkar/SmartUDM/40GB.RPT

Coincidentally, both case #1 and case #2 had problems with bad sectors
on Seagate Barracuda 40GB hard discs.

- Franc Zabkar

 

[Franc Zabkar]

news:[email protected]...

| Case #1
| -------
|
| The PC with the NTFS partition had an inaccessible registry file,
| c:\windows\system32\config\system. It couldn't be deleted, copied, or
| renamed, ...
|
| CHKDSK found many problems, including an MFT issue, all of which were fixed.

That error seems to indicate corruption within the streams and other file
handling. Did the computer get rapidly shut off by power disruption, or
perhaps suffered power flucuations?

I believe it just failed to power up one morning. Seagate's SeaTools
for DOS found lots of bad sectors on the HD but managed to repair them
all. I suspect that the drive is on the way out.

http://support.microsoft.com/kb/308041
Resources for troubleshooting startup problems in Windows XP
http://support.microsoft.com/kb/307654
How to install and use the Recovery Console in Windows XP
http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c28621675.mspx
XP Professional Resource Kit - Troubleshooting Disks and File Systems

Excerpt http://support.microsoft.com/kb/314835/en-us:

If you run CHKDSK online, the code that actually performs the verification
resides in utility DLLs, for example Untfs.dll and Ufat.dll. The
verification routines that CHKDSK invokes are the same routines that run
when a volume is verified through the Windows Explorer or Disk Management
graphical user interface.
However, if CHKDSK is scheduled to run when the computer restarts, the
binary module that contains the verification code is Autochk.exe, a native
Windows program. Because Autochk.exe runs early in the computer's startup
sequence, Autochk.exe does not have the benefit of virtual memory or of
other Win32 services.
Autochk.exe generates the same kind of text output that the Chkdsk.exe
utility DLLs generate.

I notice that the recovery console version of CHKDSK has only two
command line options whereas the "online" version has a lot more.

NOTE where the information is obtained from/used.

Microsoft Windows 2000 uses the NTFS file system version 3.0, and Windows
XP uses the NTFS file system version 3.1.
The MBR created by a running Windows 2000 or XP OS (specifically Disk
Management) when used to install a completely blank hard drive on your
system; includes details about the Win 2k/XP *Disk Signature bytes*!

http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm
http://thestarman.pcministry.com/asm/mbr/NTLDR.htm
http://thestarman.pcministry.com/asm/mbr/ntFAT32BR.htm

The last article would have been useful for case #2. I discovered the
same information the hard way, by installing XP onto a Win9x FAT32
volume.

| Case #2
| -------
|
| ... I now tried
| FIXMBR. This command warned me that the MBR contained unknown or
| damaged code, so I went ahead and allowed it to refresh the code. It
| reported success but when I ran FIXMBR a second time, it still
| complained of unknown or damaged code.

First I would question whether you cold rebooted between the two FIXMBR
[FIXMBR {ugh} which I found to be questionable when using] trys.

I don't think I did.

Second:
http://support.microsoft.com/kb/300415/ - Diskpart Command-Line Utility

IIRC, DISKPART, when executed from the recovery console, only gives
you the option of adding or deleting a partition.

Third, did you use the proper commandline syntax for the tools?

http://support.microsoft.com/kb/247575/EN-US
Chkdsk Does Not Use Backup Boot Sector to Fix Corrupted FAT32 Boot Sector

I found this article *after* I had already done what it suggested. In
any case the backup boot sector still had to be patched.

http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/z03c621675.mspx
XP Professional Resource Kit - Tools for Troubleshooting

That's a good resource.

You're dealing with the wonders of Microsoft and NT5.1 there. Another
question would be whether the newest versions of those tools were used.

I didn't check that.

But I must say that personally, I generally try to use other's tools rather
than Microsoft's..

Well, I'd be reluctant to use Fixboot ever again.

There are other disk tools which seem to work better/easier with NTFS and
NT5 file systems. Check out Testdisk, HDAT, and MHDD.

http://www.cgsecurity.org/wiki/TestDisk_Download - now at version 6.9
http://hddguru.com/
http://hddguru.com/content/en/software/2005.10.02-MHDD/
http://www.hdat2.com/

I think I downloaded these last time we discussed NTFS in m.p.w.g_d.
In the present case, the only tools that I needed for patching the
FAT32 boot sector were Debug, Copy, and Edit, although I could have
done it all with just Debug. Scandisk fixed the FAT. Wherever possible
I try to get by with the available tools because I never know what the
customer has.

BTW Franc, you're part of the reason I posted that link for the non-GUI
Microsoft OS in here. Though you might want to get in on the ground floor of
what will likely translate to the nex-gen/new processor base coding, for
what may be used in the non-legacy Windows. Kinda like the old DOS days and
downloading betas from Microsoft's BBS before it turned into the monster it
is ... (now if only they were paying the beta testers.. hahaha)

Sorry, I'm going to try Linux instead ... eventually.

- Franc Zabkar

 

[MEB]

| On Fri, 14 Mar 2008 05:35:07 -0400, "MEB" <meb@not (e-mail address removed)>
| put finger to keyboard and composed:
|
| >|
| >| Case #1
| >| -------
| >|
| >| The PC with the NTFS partition had an inaccessible registry file,
| >| c:\windows\system32\config\system. It couldn't be deleted, copied, or
| >| renamed, ...
| >|
| >| CHKDSK found many problems, including an MFT issue, all of which were
fixed.
|
| > That error seems to indicate corruption within the streams and other
file
| >handling. Did the computer get rapidly shut off by power disruption, or
| >perhaps suffered power flucuations?
|
| I believe it just failed to power up one morning. Seagate's SeaTools
| for DOS found lots of bad sectors on the HD but managed to repair them
| all. I suspect that the drive is on the way out.

Judging by what you posted to ... et al [this date], I would suspect the
same. Seems strange though that two Seagate 40gigs would go out at
approximately the same time on separate computers.

|
| >http://support.microsoft.com/kb/308041
| >Resources for troubleshooting startup problems in Windows XP
| >http://support.microsoft.com/kb/307654
| >How to install and use the Recovery Console in Windows XP
|

http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c28621675.mspx

| >XP Professional Resource Kit - Troubleshooting Disks and File Systems
| >
| >Excerpt http://support.microsoft.com/kb/314835/en-us:
|
| > If you run CHKDSK online, the code that actually performs the
verification
| >resides in utility DLLs, for example Untfs.dll and Ufat.dll. The
| >verification routines that CHKDSK invokes are the same routines that run
| >when a volume is verified through the Windows Explorer or Disk Management
| >graphical user interface.
| > However, if CHKDSK is scheduled to run when the computer restarts, the
| >binary module that contains the verification code is Autochk.exe, a
native
| >Windows program. Because Autochk.exe runs early in the computer's startup
| >sequence, Autochk.exe does not have the benefit of virtual memory or of
| >other Win32 services.
| > Autochk.exe generates the same kind of text output that the Chkdsk.exe
| >utility DLLs generate.
|
| I notice that the recovery console version of CHKDSK has only two
| command line options whereas the "online" version has a lot more.

That's always been the complaint, the recovery console is sadly lacking in
good tools and abilities. It can be tweaked a bit, but I still think there
are better ways.

|
| >NOTE where the information is obtained from/used.
| >
| > Microsoft Windows 2000 uses the NTFS file system version 3.0, and
Windows
| >XP uses the NTFS file system version 3.1.
| >The MBR created by a running Windows 2000 or XP OS (specifically Disk
| >Management) when used to install a completely blank hard drive on your
| >system; includes details about the Win 2k/XP *Disk Signature bytes*!
|
| >http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm
| >http://thestarman.pcministry.com/asm/mbr/NTLDR.htm
| >http://thestarman.pcministry.com/asm/mbr/ntFAT32BR.htm
|
| The last article would have been useful for case #2. I discovered the
| same information the hard way, by installing XP onto a Win9x FAT32
| volume.

Well, now you have it, AND have confirmed what needs done.

|
| >| Case #2
| >| -------
| >|
| >| ... I now tried
| >| FIXMBR. This command warned me that the MBR contained unknown or
| >| damaged code, so I went ahead and allowed it to refresh the code. It
| >| reported success but when I ran FIXMBR a second time, it still
| >| complained of unknown or damaged code.
| >
| > First I would question whether you cold rebooted between the two FIXMBR
| >[FIXMBR {ugh} which I found to be questionable when using] trys.
|
| I don't think I did.

Kind of like fdisking a drive, gotta reboot.

|
| >Second:
| >http://support.microsoft.com/kb/300415/ - Diskpart Command-Line Utility
|
| IIRC, DISKPART, when executed from the recovery console, only gives
| you the option of adding or deleting a partition.
|
| >Third, did you use the proper commandline syntax for the tools?
| >
| >http://support.microsoft.com/kb/247575/EN-US
| >Chkdsk Does Not Use Backup Boot Sector to Fix Corrupted FAT32 Boot Sector
|
| I found this article *after* I had already done what it suggested. In
| any case the backup boot sector still had to be patched.

Oh well, now you know.

|
|

http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/z03c621675.msp

x
| >XP Professional Resource Kit - Tools for Troubleshooting
|
| That's a good resource.
|
| > You're dealing with the wonders of Microsoft and NT5.1 there. Another
| >question would be whether the newest versions of those tools were used.
|
| I didn't check that.

Try on the Reskit area, and TechNet.

|
| > But I must say that personally, I generally try to use other's tools
rather
| >than Microsoft's..
|
| Well, I'd be reluctant to use Fixboot ever again.

Oh, I NEVER will again.

|
| > There are other disk tools which seem to work better/easier with NTFS
and
| >NT5 file systems. Check out Testdisk, HDAT, and MHDD.
|
| >http://www.cgsecurity.org/wiki/TestDisk_Download - now at version 6.9
| >http://hddguru.com/
| >http://hddguru.com/content/en/software/2005.10.02-MHDD/
| >http://www.hdat2.com/
|
| I think I downloaded these last time we discussed NTFS in m.p.w.g_d.
| In the present case, the only tools that I needed for patching the
| FAT32 boot sector were Debug, Copy, and Edit, although I could have
| done it all with just Debug. Scandisk fixed the FAT. Wherever possible
| I try to get by with the available tools because I never know what the
| customer has.

Okay, I carry[ied] three floppy disk cases [test tools, drive tools, and
boot floppies], XP CD, and a Live CD with me when out servicing [also a
floppy drive and CDROM drive and cables].
But your right, keeping the mind fresh with the old tried and true
techniques, gives you the ability to just sit down at the problem computer
and work away.
You're a pretty smart guy. I can't even remember all those techniques
anymore. Heck those links came from mht files I saved locally just so I can
refresh my memory.

|
| >BTW Franc, you're part of the reason I posted that link for the non-GUI
| >Microsoft OS in here. Though you might want to get in on the ground floor
of
| >what will likely translate to the nex-gen/new processor base coding, for
| >what may be used in the non-legacy Windows. Kinda like the old DOS days
and
| >downloading betas from Microsoft's BBS before it turned into the monster
it
| >is ... (now if only they were paying the beta testers.. hahaha)
|
| Sorry, I'm going to try Linux instead ... eventually.

Well, progress has been made, they might surprise you. You'll LOVE the
command line abilities.

|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

MEB
http://peoplescounsel.orgfree.com

 

[Franc Zabkar]

news:[email protected]...

| Well, I'd be reluctant to use Fixboot ever again.

Oh, I NEVER will again.

There are quite a few cases of this FIXBOOT/FAT12 problem in the
Google Groups archives.

- Franc Zabkar

 

[Franc Zabkar]

There are quite a few cases of this FIXBOOT/FAT12 problem in the
Google Groups archives.

BTW, I can't be absolutely certain, but IIRC the FAT12 boot sector,
which was written by FIXBOOT from the recovery console, had an
MSDOS5.0 signature. I don't think this same signature exists in
AUTOCHK.EXE.

- Franc Zabkar

 

[sgopus]

Fascinating stuff Frank, I appreciate the detail, not that I actually work in
that area
I used to use an old Radio Shack Model 4 and had some nifty software, that
allowed me to view the floppy disk data track by track, it also allowed me to
alter that data or (correct it), I think it was called superzap or something
along that line, can't find anything like it for todays computers.
Course back then it was using NEWDOS and or LDOS , nothing like windows of
today.

I recently had to repair file system corruption for two XP users, one
with a FAT32 partition, the other with NTFS. Unfortunately I have
little experience with XP so I struggled quite a bit. Anyway I
discovered that Microsoft's disc repair tools were flawed in several
ways.


Case #2
-------

The PC with the FAT32 partition could not boot. It produced a "missing
NTLDR" error. This suggested that the MBR and boot sector were
probably OK, and that the error was somewhere in the FATs or directory
structure. I booted into the repair console of an XP CD and tried a
[snip]


Now I was getting desperate. I took the USB drive to my Windows 98SE
box and to my surprise Explorer was able to see the entire drive with
all the original files apparently still intact! SCANDISK determined

Because "I have little experience with XP" .. i don't see that
you mention that the [NTLdr] file ( and the [NTDetect.com] file )
is there or that you tried with a new copy off the WinXP CD in
case of corruption.

A DIR from within the XP repair console produced some kind of "could
not enumerate" error, so I couldn't see any files at all. CHKDSK was
unable to recover the file system. In desperation I tried a FIXBOOT,
hoping that it would work much like SYS.COM in a Win9x machine. That
is, I was hoping that FIXBOOT would fix the boot files, eg NTLDR and
whatever else was required. Instead, AFAICT, FIXBOOT just trashed the
boot sector. :-(

BTW, I had no software tools with me at this time, only an XP CD.

[snip]

So what was wrong? I looked closely at the boot sector again and found
that it was a Win9x boot sector, ie there were references to IO.SYS,
MSDOS.SYS and WINBOOT.SYS, but no reference to NTLDR. WTF!

Ok, but since i don't know that there normally is, i mentioned
the above just in case.

AFAICT, the original problem was damage to the first copy of the FAT.
This was repaired by Scandisk. Both NTxxx files were intact. In a
Win98 box I was able to see the NTxxx files as well as autoexec.bat
and config.sys. The last two files had sizes of 0. IIRC io.sys and
msdos.sys were also there, and both also had file sizes of 0.

After I had the drive booting in the original machine, I ran Seagate's
SeaTools for DOS hard disc diagnostic. It found 6 bad sectors which it
was able to repair. A subsequent check with SmartUDM reported 56
reallocated sectors, suggesting that the drive may be on its way out.

See http://www.users.on.net/~fzabkar/SmartUDM/40GB.RPT

Coincidentally, both case #1 and case #2 had problems with bad sectors
on Seagate Barracuda 40GB hard discs.

- Franc Zabkar

 

[Franc Zabkar]

news:[email protected]...

| On Fri, 14 Mar 2008 05:35:07 -0400, "MEB" <meb@not (e-mail address removed)>
| put finger to keyboard and composed:
|
| >news:[email protected]...

| >| ... I now tried
| >| FIXMBR. This command warned me that the MBR contained unknown or
| >| damaged code, so I went ahead and allowed it to refresh the code. It
| >| reported success but when I ran FIXMBR a second time, it still
| >| complained of unknown or damaged code.
| >
| > First I would question whether you cold rebooted between the two FIXMBR
| >[FIXMBR {ugh} which I found to be questionable when using] trys.
|
| I don't think I did.

Kind of like fdisking a drive, gotta reboot.

I can see why you would need to reboot before any newly created
partitions and logical drives would be detected, but I can't see why
you would need to do the same after refreshing the code in the MBR.
AFAIK, the MBR code doesn't remain in RAM after booting (it is
overwritten by the active partition's boot sector), so FIXMBR would
always need to look for it on the HD, not in memory.

See http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm

====================================================================
Once the BIOS identifies its target boot drive, then it looks for boot
information to start the operating system boot process. If it is
searching a hard disk, it looks for a master boot record at cylinder
0, head 0, sector 1, the first sector on the disk.

If a Master Boot Record is found, it is read into memory at location
0000:7c00 and INT 19 jumps to memory location 0000:7c00 ... . At this
point, the BIOS attempts to move control of the computer from the BIOS
to the actual operating system.

Next, the small program in the Master Boot Record will attempt to
locate an active (bootable) partition in the hard drives partition
table. If such a partition is found, the boot sector of that partition
is also read into memory at location 0000:7C00 and then MBR program
itself jumps to memory location 0000:7C00.
====================================================================

- Franc Zabkar

 

[MEB]

| On Mon, 17 Mar 2008 07:30:23 +1100, Franc Zabkar
| <[email protected]> put finger to keyboard and composed:
|
| >On Sun, 16 Mar 2008 02:49:15 -0400, "MEB" <meb@not (e-mail address removed)>
| >put finger to keyboard and composed:
| >
| >>| >
| >>| Well, I'd be reluctant to use Fixboot ever again.
| >>
| >> Oh, I NEVER will again.
| >
| >There are quite a few cases of this FIXBOOT/FAT12 problem in the
| >Google Groups archives.
|
| BTW, I can't be absolutely certain, but IIRC the FAT12 boot sector,
| which was written by FIXBOOT from the recovery console, had an
| MSDOS5.0 signature. I don't think this same signature exists in
| AUTOCHK.EXE.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

I sent you, from the master site address, some zipped *readable text* of a
few files from XP PRO which might be of interest you [though you probably
already did]. Look at the command sequences, messages, and other. At
minimum, they give some search strings to work from when playing around in
XP and a hexeditor.

* MEB
http://peoplescounsel.orgfree.com
--

 

[MEB]

| On Sun, 16 Mar 2008 02:49:15 -0400, "MEB" <meb@not (e-mail address removed)>
| put finger to keyboard and composed:
|
| >|
| >| On Fri, 14 Mar 2008 05:35:07 -0400, "MEB" <meb@not (e-mail address removed)>
| >| put finger to keyboard and composed:
| >|
| >| >|
| >| >| ... I now tried
| >| >| FIXMBR. This command warned me that the MBR contained unknown or
| >| >| damaged code, so I went ahead and allowed it to refresh the code. It
| >| >| reported success but when I ran FIXMBR a second time, it still
| >| >| complained of unknown or damaged code.
| >| >
| >| > First I would question whether you cold rebooted between the two
FIXMBR
| >| >[FIXMBR {ugh} which I found to be questionable when using] trys.
| >|
| >| I don't think I did.
| >
| > Kind of like fdisking a drive, gotta reboot.
|
| I can see why you would need to reboot before any newly created
| partitions and logical drives would be detected, but I can't see why
| you would need to do the same after refreshing the code in the MBR.
| AFAIK, the MBR code doesn't remain in RAM after booting (it is
| overwritten by the active partition's boot sector), so FIXMBR would
| always need to look for it on the HD, not in memory.
|
| See http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm
|
| ====================================================================
| Once the BIOS identifies its target boot drive, then it looks for boot
| information to start the operating system boot process. If it is
| searching a hard disk, it looks for a master boot record at cylinder
| 0, head 0, sector 1, the first sector on the disk.
|
| If a Master Boot Record is found, it is read into memory at location
| 0000:7c00 and INT 19 jumps to memory location 0000:7c00 ... . At this
| point, the BIOS attempts to move control of the computer from the BIOS
| to the actual operating system.
|
| Next, the small program in the Master Boot Record will attempt to
| locate an active (bootable) partition in the hard drives partition
| table. If such a partition is found, the boot sector of that partition
| is also read into memory at location 0000:7C00 and then MBR program
| itself jumps to memory location 0000:7C00.
| ====================================================================
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

And how does it do this when it has already been accessed upon bootup, and
found as faulty. The disk couldn't be accessed properly, so how can it now,
when the code and jumps were wrong to start with and have not been refreshed
yet.. You could see it with an editor, but the BIOS has already transferred
activity elsewhere [particularly in NT].

Are you indicating that there were no errors when attempting to access the
hard disk after doing so?
______
* MEB
http://peoplescounsel.orgfree.com

 

[Bill in Co.]

One of the worst "quirks" about Scandisk in WinXP is just how limited it is,
both in choices, and in logging capabilities (like in comparison to any
Win9x). It really sucks. No real selection choices, and NO real logs
(except sometimes some stuff can be found in Event Viewer - after you sort
it all out, and AFTER it has replaced whatever it felt like, carte blanche,
no questions asked). SFC in WinXP is a step backwards, in many respects.

 

[MEB]

| One of the worst "quirks" about Scandisk in WinXP is just how limited it
is,
| both in choices, and in logging capabilities (like in comparison to any
| Win9x). It really sucks. No real selection choices, and NO real logs
| (except sometimes some stuff can be found in Event Viewer - after you sort
| it all out, and AFTER it has replaced whatever it felt like, carte
blanche,
| no questions asked). SFC in WinXP is a step backwards, in many respects.
|

I would tend to agree, but then even in Win9X I preferred to use DiskTune
and DiskMinder [from Nuts and Bolts] or other tools, at least until they
stopped working correctly [the suite of tools; the disk tools still work,
just tried that during the last test period].

I think, though, we tend to forget that XP was created to allow regular
non-techie people to use NT, and was limited to ensure they didn't mess up
to much. Kind of like dumbing down the control, and placing it in
Microsoft's hands... just look at VISTA, even more *out of your hands*
unless you know what to do.

* MEB
http://peoplescounsel.orgfree.com

 

[Bill in Co.]

One of the worst "quirks" about Scandisk in WinXP is just how limited it
is,
both in choices, and in logging capabilities (like in comparison to any
Win9x). It really sucks. No real selection choices, and NO real logs
(except sometimes some stuff can be found in Event Viewer - after you
sort
it all out, and AFTER it has replaced whatever it felt like, carte
blanche,
no questions asked). SFC in WinXP is a step backwards, in many
respects.

I would tend to agree, but then even in Win9X I preferred to use DiskTune
and DiskMinder [from Nuts and Bolts] or other tools, at least until they
stopped working correctly [the suite of tools; the disk tools still work,
just tried that during the last test period].

I think, though, we tend to forget that XP was created to allow regular
non-techie people to use NT, and was limited to ensure they didn't mess up
too much. Kind of like dumbing down the control, and placing it in
Microsoft's hands... just look at VISTA, even more *out of your hands*
unless you know what to do.

Yeah, tell me about it.

 

[... et al.]

I recently had to repair file system corruption for two XP users, one
with a FAT32 partition, the other with NTFS. Unfortunately I have
little experience with XP so I struggled quite a bit. Anyway I
discovered that Microsoft's disc repair tools were flawed in several
ways.

Case #2
-------

The PC with the FAT32 partition could not boot. It produced a "missing
NTLDR" error. This suggested that the MBR and boot sector were
probably OK, and that the error was somewhere in the FATs or directory
structure. I booted into the repair console of an XP CD and tried a [snip]

Now I was getting desperate. I took the USB drive to my Windows 98SE
box and to my surprise Explorer was able to see the entire drive with
all the original files apparently still intact! SCANDISK determined

Because "I have little experience with XP" .. i don't see that
you mention that the [NTLdr] file ( and the [NTDetect.com] file )
is there or that you tried with a new copy off the WinXP CD in
case of corruption.

A DIR from within the XP repair console produced some kind of "could
not enumerate" error, so I couldn't see any files at all. CHKDSK was

(yes, sorry. I snipped a line to much earlier perhaps.)

unable to recover the file system. In desperation I tried a FIXBOOT,
hoping that it would work much like SYS.COM in a Win9x machine. That
is, I was hoping that FIXBOOT would fix the boot files, eg NTLDR and
whatever else was required. Instead, AFAICT, FIXBOOT just trashed the
boot sector. :-(

BTW, I had no software tools with me at this time, only an XP CD.

[snip]

So what was wrong? I looked closely at the boot sector again and found
that it was a Win9x boot sector, ie there were references to IO.SYS,
MSDOS.SYS and WINBOOT.SYS, but no reference to NTLDR. WTF!

Ok, but since i don't know that there normally is, i mentioned
the above just in case.

AFAICT, the original problem was damage to the first copy of the FAT.
This was repaired by Scandisk. Both NTxxx files were intact. In a
Win98 box I was able to see the NTxxx files as well as autoexec.bat
and config.sys. The last two files had sizes of 0. IIRC io.sys and
msdos.sys were also there, and both also had file sizes of 0.

I read all the above and don't have anything useful to add. It's
interesting and i learn from reading your procedures and
following the links you and MEB posts (as usual). Thanks.

After I had the drive booting in the original machine, I ran Seagate's
SeaTools for DOS hard disc diagnostic. It found 6 bad sectors which it
was able to repair. A subsequent check with SmartUDM reported 56
reallocated sectors, suggesting that the drive may be on its way out.

See http://www.users.on.net/~fzabkar/SmartUDM/40GB.RPT

Coincidentally, both case #1 and case #2 had problems with bad sectors
on Seagate Barracuda 40GB hard discs.

Perhaps suggesting, but perhaps not necessarily. I have a 60 GB
Seagate HDD and i checked it with a different SMART viewing
program, DiskCheckup, in October 1996. It had 5 reallocated
sectors then and it still have 5 when i checked it with SMARTUDM
today. And that HDD have been used for several hours almost daily
in the 17 months in between.

BTW, i just downloaded SMARTUDM. It unarchived fine and the
DOS-program runs fine. However, the four text-files in the
archive show mostly as gibberish .. i tried a few different
text-editors, they all show it the same .. is it the same for you?