F
FUBARinSFO
PROBLEM
Windows XP SP3 detects a disk problem at boot time and runs chkdsk.
Chkdsk displays screenfuls of NTFS index and file system corruption
messages with incomprehensible numeric files and indexes as targets.
File system may or may not be "fixed", but the system proceeds to boot
into Windows logon. Computer seems to be OK, and no "disk" errors in
Event Log.
On subsequent reboots, Windows detects errors and continues to invoke
chkdsk to "fix" them, which it proceeds to do with screenfuls of
adjustments to the file system. But this doesn't fix the problem, and
corrupted files are eventually identified on a large data drive (200GB
Seagate drive, attached as Secondary Master to a Promise Ultra100 TX2
IDE PCI controller). Files are moved off the drive in question, but
tests of some large .zip and .bkf files show them to be corrupt, and
some txt files have unreadable data. The NTFS file system has been
corrupted and the drive has to be reformatted.
Upon reformat and reboot, Windows detects an error in the freshly-
formatted file system and invokes chkdsk again, which identifies cross-
linked files and bad cluster attributes, which it proceeds to "fix".
No files have been loaded on the newly-formatted drive at this point.
Attempt to run chkdsk from a command window fails, absent using the "/
f" parameter. Running 'chkdsk /f' proceeds to make corrections to a
nominally bad file system. Complete removal of the partition is now
indicated.
Upon removal of the logical disk drive and the extended partition,
drive presents itself as a 128GB drive to Drive Manager (it is a 200GB
Seagate drive). This looks like the old "128GB / 137GB" 48-bit LBA
problem, but since this problem was solved with Windows XP SP2 and
this is SP3, that solution will probably not hold here.
Googling around for a while yields mainly the old Windows XP SP1/SP2
or registry fix for large LBA drives, and no clear solution. Data loss
stories are evident ("Running chkdsk Results in a 220GB Loss Of Data?
Why? How? Help!!!"
http://groups.google.com/group/micr...hl=en&lnk=gst&q=ultra100+tx2#b56199509fc5deca)
DIAGNOSIS
The problem is with Windows XP and its rejection of the newer Promise
Ultra IDE controller device drivers, which are unsigned and not
Microsoft certified.
Windows XP SP3 automatically, intentionally and silently reverts to an
old version of Promise Ultra IDE driver ultra.sys, version 1.43, which
does not support 48-bit large LBA drives.
As a result, a system that has been otherwise functioning perfectly
well will fail and experience data corruption on any large hard drive
attached to a Promise controller after Windows is allowed to upgrade,
restore or repair itself auotmatically, and may emit only a single
error message to the System Event Log referencing NTFS file system
corruption.
DISCUSSION
It turns out that in this case my system contracted a nasty root kit
infection, for which I both ran System File Check and perhaps shortly
thereafter ran a repair and upgrade from CD from SP2 to SP3. In any
case either of these operations would have been enough to restore the
older Microsoft-certified ultra.sys driver. While I had had this
problem and solved it in the past, I had forgotten about this effect
at this point.
The Windows default Promise ultra.sys IDE driver, which does not
support large 48-bit LBA drives, can be identified by the string
'Promise Ultra IDE Controller, v1.43 (Build 0603)' per Device
Manager. Windows will restore this driver on an upgrade from SP2 to
SP3, when System File Check is invoked to restore known versions of
its drivers, or when the Windows installation is repaired from the
distribution CD. It even will do it on an unattended install when you
try to install the current driver, since the current driver loses out
in points with Windows Setup's contention and driver installation
system. It does this because the default driver is signed and
Microsoft certified, whereas the newer drivers are not. While there
are lines in setuplog.txt identifying this rejection, the versions are
not identified and no posting is made in the System Event Log.
Even though the system may have been set up at some point with the
correct and most recent Promise Ultra100 TX2 (or Ultra33 TX2) drivers,
since these Promise drivers are unsigned and not certified by
Microsoft, Windows setup rejects the installed or otherwise available
drivers.
The two most recent compatible but unsigned drivers for this
controller are:
WinXP Promise Ultra100 (tm) IDE Controller version 2.0.0.42
(3/28/2003)
WinXP Promise Ultra100 (tm) IDE Controller version 2.0.0.43
(5/16/2003)
It may have been possible to avoid any data corruption at all by
promptly manually installing the newer drivers immediately after the
use of sfc or the repair from CD. Since some of the drive data has
already been corrupted at this point, and the drive reformatted, this
is not a verified solution, but rather a diagnosis that could lead to
a full solution with no loss of data in the future if one were alert
enough to catch this problem in time.
-- Roy Zider
Windows XP SP3 detects a disk problem at boot time and runs chkdsk.
Chkdsk displays screenfuls of NTFS index and file system corruption
messages with incomprehensible numeric files and indexes as targets.
File system may or may not be "fixed", but the system proceeds to boot
into Windows logon. Computer seems to be OK, and no "disk" errors in
Event Log.
On subsequent reboots, Windows detects errors and continues to invoke
chkdsk to "fix" them, which it proceeds to do with screenfuls of
adjustments to the file system. But this doesn't fix the problem, and
corrupted files are eventually identified on a large data drive (200GB
Seagate drive, attached as Secondary Master to a Promise Ultra100 TX2
IDE PCI controller). Files are moved off the drive in question, but
tests of some large .zip and .bkf files show them to be corrupt, and
some txt files have unreadable data. The NTFS file system has been
corrupted and the drive has to be reformatted.
Upon reformat and reboot, Windows detects an error in the freshly-
formatted file system and invokes chkdsk again, which identifies cross-
linked files and bad cluster attributes, which it proceeds to "fix".
No files have been loaded on the newly-formatted drive at this point.
Attempt to run chkdsk from a command window fails, absent using the "/
f" parameter. Running 'chkdsk /f' proceeds to make corrections to a
nominally bad file system. Complete removal of the partition is now
indicated.
Upon removal of the logical disk drive and the extended partition,
drive presents itself as a 128GB drive to Drive Manager (it is a 200GB
Seagate drive). This looks like the old "128GB / 137GB" 48-bit LBA
problem, but since this problem was solved with Windows XP SP2 and
this is SP3, that solution will probably not hold here.
Googling around for a while yields mainly the old Windows XP SP1/SP2
or registry fix for large LBA drives, and no clear solution. Data loss
stories are evident ("Running chkdsk Results in a 220GB Loss Of Data?
Why? How? Help!!!"
http://groups.google.com/group/micr...hl=en&lnk=gst&q=ultra100+tx2#b56199509fc5deca)
DIAGNOSIS
The problem is with Windows XP and its rejection of the newer Promise
Ultra IDE controller device drivers, which are unsigned and not
Microsoft certified.
Windows XP SP3 automatically, intentionally and silently reverts to an
old version of Promise Ultra IDE driver ultra.sys, version 1.43, which
does not support 48-bit large LBA drives.
As a result, a system that has been otherwise functioning perfectly
well will fail and experience data corruption on any large hard drive
attached to a Promise controller after Windows is allowed to upgrade,
restore or repair itself auotmatically, and may emit only a single
error message to the System Event Log referencing NTFS file system
corruption.
DISCUSSION
It turns out that in this case my system contracted a nasty root kit
infection, for which I both ran System File Check and perhaps shortly
thereafter ran a repair and upgrade from CD from SP2 to SP3. In any
case either of these operations would have been enough to restore the
older Microsoft-certified ultra.sys driver. While I had had this
problem and solved it in the past, I had forgotten about this effect
at this point.
The Windows default Promise ultra.sys IDE driver, which does not
support large 48-bit LBA drives, can be identified by the string
'Promise Ultra IDE Controller, v1.43 (Build 0603)' per Device
Manager. Windows will restore this driver on an upgrade from SP2 to
SP3, when System File Check is invoked to restore known versions of
its drivers, or when the Windows installation is repaired from the
distribution CD. It even will do it on an unattended install when you
try to install the current driver, since the current driver loses out
in points with Windows Setup's contention and driver installation
system. It does this because the default driver is signed and
Microsoft certified, whereas the newer drivers are not. While there
are lines in setuplog.txt identifying this rejection, the versions are
not identified and no posting is made in the System Event Log.
Even though the system may have been set up at some point with the
correct and most recent Promise Ultra100 TX2 (or Ultra33 TX2) drivers,
since these Promise drivers are unsigned and not certified by
Microsoft, Windows setup rejects the installed or otherwise available
drivers.
The two most recent compatible but unsigned drivers for this
controller are:
WinXP Promise Ultra100 (tm) IDE Controller version 2.0.0.42
(3/28/2003)
WinXP Promise Ultra100 (tm) IDE Controller version 2.0.0.43
(5/16/2003)
It may have been possible to avoid any data corruption at all by
promptly manually installing the newer drivers immediately after the
use of sfc or the repair from CD. Since some of the drive data has
already been corrupted at this point, and the drive reformatted, this
is not a verified solution, but rather a diagnosis that could lead to
a full solution with no loss of data in the future if one were alert
enough to catch this problem in time.
-- Roy Zider