This should get a prize for the PC compatible's most obscure error
message. It usually means you haven't made the primary partition
bootable or, in Microsoft-speak, 'Active'. Use
FDISK
to fix this. Don't fret, you won't have to repartition or
reformat anything unless you have no primary partition at all.
The earliest true-blue PCs had a BASIC interpreter built in, just like many
other home computers those days. Even today, the Master Boot Record (MBR)
code on your harddisk jumps to the BASIC ROM if it doesn't find any active
partitions. Needless to say, there's no such thing as a BASIC ROM in today's
compatibles, and this action ends in the above error message.
Try using a slower mode or disable fast modes altogether. Mode 3 and
especially mode 4 are very sensitive to timing problems, and not all
adapters follow the ATA-2 specification really closely. Don't dismiss
the possibility too easily: if you changed anything on your system, it
is very well possible that a drive which marginally worked so far now
starts to corrupt data.
Some controllers seem to configure themselves according to the
capabilities of the master drive. This can mean trouble if the slave
handles only slower modes.
Moreover, check your cables, and ensure they aren't too long (see
Q
5.4
). Removable drive brackets may
also cause problems with fast PIO modes for roughly the same reasons.
No. All modern drives support error management, which completely hides
any bad sectors that may be on the disk before leaving the
factory. Even a single bad sector is sufficient grounds to return the
drive under warranty. If you want to continue using it, the drive
should be viewed with the utmost suspicion.
Western Digital's wdat_ide.exe
utility can hide grown bad
sectors on many Caviar disks.
There is one exception. Under rare circumstances, use of bad (too
fast) timing by the disk adapter can cause bad sectors on a disk. This
type of error can be fixed simply by writing fresh data to these
sectors, as there is no actual media defect.
Often, this is caused by the use of block mode (see
Q
10.6
for an explanation). Large blocks can
take a long time to transfer; during the transfer, interrupts are disabled
and the serial ports are not serviced by the CPU. Eventually, the buffer for
incoming data may overflow, leading to overruns and CRC errors.
The solution is to reduce the number of sectors per block, if possible, or
disabling block mode altogether. 16550 compatible serial ports have a larger
buffer, but with excessively large block sizes this problem may still occur.
There appears to be an awful lot of confusion about this subject, partly
due to some unhappy terminology.
In the most literal sense, no ATA(-2,-PI) drive will allow 32-bit access.
Data is transferred to and from the drive over a 16 bit bus. However, many
local bus interfaces are capable of combining two 16-bit words into a 32-bit
doubleword when reading data from the disk, and the reverse when writing. This
way, data transfer between the CPU and the interface can be done in 32-bit
chunks. This is often called '32-bit access', although '32-bit host
bus transfers' would be a better name.
With 32-bit host bus transfers, more efficient use is made of the
computer's bus and CPU. On the other hand, these are seldom the bottleneck,
so don't expect miracles from this feature. Windows' 32-bit disk and file
access are completely unrelated issues and the subject of question
8.10
and
8.11
.
There are numerous reasons why this can fail; you will more easily be able to
do something about it (or decide if you want to fix it in the first place)
once you know some background.
Windows' 32-bit disk access (32BDA) is a bit of a misnomer, actually,
since it has nothing to do with 32-bit data transfers. A slightly better
name for it is 'FastDisk'. It is a feature of Windows in 386 Enhanced
mode that allows one to replace the BIOS' disk routines by Windows' own
routines that work in protected mode. A much better name, then, would be
"protected mode controller access". For some reason Microsoft decided
not to use the latter.
Anyway, the main advantage of this feature is that it allows Windows to use
virtual memory for its DOS sessions. Without 32-bit disk access, DOS
sessions cannot be swapped out and every DOS box takes 640k of real
memory. Because it also reduces the number of switches between virtual and
protected mode Windows has to make, it gives a slight performance
improvement as well, but usually nothing dramatic. Only if 32BDA is used
together with Windows for Workgroups' 32-bit file access feature, it
will eliminate these mode switches altogether (at least for most disk
operations), which gives a far more interesting performance boost.
Unfortunately, the standard FastDisk routines that are internal to windows,
called *wdctrl
, are severely limited in their capabilities. The
*wdctrl
software understands nothing of non-IDE hardware (e.g. SCSI),
more than two harddrives, drives with more than 1024 cylinders, 32-bit host
bus transfers, block transfers, or ATAPI CD-ROM drives on the primary
channel. If you use any of these things, 32-bit disk access won't work
unless you have a *wdctrl
replacement.
Today, that means that 32-bit disk access won't work 'out of the box' for
most of us.
Most interfaces that are incompatible with *wdctrl
come with their own
FastDisk routines (usually with a .386
extension). For the rest of
you, many drive manufacturers offer replacement FastDisk software. Many
drive manufacturers have such drivers on their WWW sites these days; take a
look in the net.resource guide below. You can also contact your vendor to
find out what is available. Last but not least, the ontrackw.386
driver in
ftp://ftp.ontrack.com/pub/software/dmpatch.zip
is
reported to work fine on all drives even if you don't use Disk Manager.
Most of these drivers won't give you 32-bit disk access if you have an ATAPI
CD-ROM on the same cable as the harddisk. Only a few CD-ROMs come with a
special VxD driver which does the job.
Note: these drivers are incompatible with the Stealth feature of some
versions of Quarterdeck's QEMM. Quarterdeck's fix can be found on
ftp://ftp.wdc.com/drivers/hdutil/32bda.com
.
The idiosyncrasies of the 32-bit disk access feature with respect to disk
hardware has led to the popular myth that 32-bit file access has similar
problems. However, that's all it is: a myth. If 32-bit file access fails,
you should first check your filesystem and the programs that use it. As
little as a single open file, e.g. from a printer spooler, will cause 32BFA
to fail. Oh, and put DEVICE=C:\WINDOWS\IFSHLP.SYS
in
your CONFIG.SYS
, and make sure your SYSTEM.INI
contains the
correct magic incantations (vfat.386
, vcache.386
). If this
doesn't help, there's a first rate FAQ on this topic (see the net.resource
guide for details).
The culprit usually is a virus. Do get a recent virus scanner.
If that turns out negative, it may also be DOS (real-mode) driver that loads
in the CONFIG.SYS
or AUTOEXEC.BAT
, or an old version of EZDrive/Disk
Manager loading from the MBR.
See the next question.
If you've used Win95's fdisk
utility to partition your drive, you may
run across a nasty bug.
Win95 supports extended int13 calls to break the 8GB barrier. To avoid
problems with old versions of DOS, partitions extending beyond 8GB must be
made invisible. Unfortunately, the Win95 FDISK
sometimes hides
partitions this way even if your drive is much smaller than 8GB.
Incidentally, this also hides them from all other operating systems,
including old versions of DOS, and can cause all kinds of problems.
Under circumstances, these new partition types can completely mess up
things when going from the Win95 graphical shell to MS-DOS mode. Drive
contents may appear to be corrupted or be replaced by the contents of
C:. Don't try anything fancy when this happens; it is really easy to
corrupt your data. Don't use the "Restart in MS-DOS mode" option and don't
run programs configured to run in MS-DOS mode. MS-DOS windows are still
fine.
The most comfortable way to fix this is to change the partition types using
Partition Magic
, but ONLY
version 2.03 or later. You can get an update patch for older versions.
The alternative is to back up your data and repartition using FDISK
/X
, which disables the use of the new partition types, or DOS 6
FDISK
. Also be sure to apply the Win95 ios
bugfix and other fixes
available from
Microsoft's web site
.
If you have a Triton II or Natoma based board, the retail version of Win95
may not recognize the PIIX3 interface. This will trigger an entertaining bit
of Plug'n'Pray magic which eventually causes the BIOS to disable the
secondary IDE channel on the next reboot.
To determine if this is really your problem, go into the device manager and
click on Hard Disk Controllers
. If you see the following devices listed:
Primary IDE Controller (single FIFO)
Standard Dual PCI IDE Controller
Standard IDE
ESDI Hard Disk Controller/
your Win95 mshdc.inf
needs a little update. You can download this from
The Win95 busmastering drivers sometimes have trouble co-operating with
older harddisks and ATAPI CD-ROMs. Try installing the latest drivers.
If that doesn't help, you could try this registry hack. Move all
old devices to the secondary port. Back up the registry
(system.dat
and user.dat
in the Win95 directory). Start
regedit
and look for
If the CD-ROM is connected to the secondary channel, make sure this channel
is enabled. Some BIOSes will enable the channel only if one or more
harddisks using this channel are defined in the setup; in that case, you
can't avoid putting the CD on the same cable as a harddisk until you manage
to get your BIOS updated.
You may also get trouble if the CD-ROM is jumpered as slave and there's no
master on its channel.
Finally, the PIO mode (speed) used by the interface may be too high,
especially if the CD-ROM shares its cable with a harddisk. Many
interface drivers and BIOSes are not ATAPI-aware and don't take the
CD-ROM into account when determining the maximum possible speed. The
best fix is to move the CD-ROM to a different channel. Manually
lowering the mode a notch or two should also help; this is usually
done either through the BIOS setup or by passing options to a device
driver in the CONFIG.SYS
.
Next Chapter, Previous Chapter
Table of contents of this chapter,
General table of contents
Top of the document,
Beginning of this Chapter