On that special day, Aldo Larrabiata, (
[email protected]) said...
The 1080 MB HD is mounted on my server, with an Asus TXP4, a K6-200 CPU and
a BIOS able to recognize up to 32 MB. There's no translation software. One
primary hidden 7.8 MB partition and one 1 GB extended with a logical disk in
it (I use this scheme in order not to modify the letters when I move disks
from one computer to another one).
Interesting. that means, you have a very small FAT16 partiton in front,
and another larger one (FAT16 or FAT32?) after that. I am not quite sure
if the Windows you are using, can handle that, especially with a
partition that is *hidden*. Maybe the partition table was "fixed" by the
removal tool in a way, that made the result even worse than before the
cure. Virus scanners aren't always prepared to deal with behaviour
untypical to the OS they are used under (I wonder if they are using own
hard disk access routines to fix things like weird partition table
entries, or if they make use of the OS tools). Ask Zvi Netiv about that,
he will probably be able to find out what went wrong.
The 40 GB is presently mounted on my main computer, with an Asus A7N8X and
an Athlon 2400+. This disk was formerly installed on the K6 with a
translation utility provided by Maxtor and limited to 32 GB by the disk
jumper. It was recognized as 40 GB thanks to the disk manager. When I put it
on my A7N8X, one year ago,I removed the jumper, I removed also the utility
with the help of the Maxtor tools and I resetted the disk. I repartitioned
it with 2 primary partitions (40 MB each) one hidden, one bootable, an
extended one containing 4 big logical units. Everything went fine. Except
sometimes, scandisk under DOS says that the size is reported as incorrect
and it adjusts it. This has been happening quite often over years with
several disks, both IDE and SCSI and on three computers (Asus P55-TP4XE +
P100, Asus TXP4 + K6-200 and Asus A7N8X Deluxe + Athlon 2400+)
I would back up all important data from that hard disk and *wipe* it
with a Maxtor low level formatting tool, just to make sure that the
changed hard disk geometry access doesn't mess the partition table up.
The hidden partition might also get in the way of your *boot*able
partition, if the OS thereon is of the Win9x kind, which would normally
only boot from the first primary partition, which is supposed to be
right at the beginning of the hard disk. You set up your disks in a very
unusual way, and again I suspect that the fix ruined the partiton table,
trying to make the computer boot from the first partition of all, and
maybe shifting the info of the second primary partition to the first
one.
1- Server problem:
Today (since netsky virus removal), The 1080 MB of the server is fine under
DOS but the driver is marked with an exclamation mark under Win98 system
properties. Noway to remove the IDE driver in order to install it again.
Look into another tab of your system properties, it shouöd be the last
one (in German it is called "Leistungsmerkmale", which translates to
performance signs). Look if there is an entry that the partition is run
in "compatibility mode", and read the details. Maybe you'll have to
remove a "Noide" entry from the registry, or check for bad real mode
drivers in the Config.sys or Autoexec.bat
When I pased the fixnetsky, the first time (prior to knowing that the driver
was corrupted) it stopped telling me that there were errors on the disk
always on the same file (I ran it 4 times). I launched scandiskw and it made
a mess.
I attempted to format the disk under Win but it didn't complete. I did it
under DOS, verifying the job under DOS & Partition Magic. I didn't find any
errors. I successfully ran a surface test.
Then, Iput some files onto it, under a windows session, through the network
(from the A7N8X computer onto the server's disk), I CRC tested them from the
server, everything was OK. I ran again scandisk on the server errors were
indicated but didn't made any correction. Then the disk appeared in error,
impossible to read it. The directories weren't present anylonger or
Ouch. The File Allocation Table went bad or was misread.
garbaged. I booted again the server under DOS. No problem.
Be careful. It might look fine for DOS (which uses a fairly direct
device access), but might still crash when using Windows. If the FAT
reading gets bad, and you save files while the machine is running in
this unstable state, you might overwrite the good FAT with bad info, and
lose files (or rather the pointers to the files).
Scandisk under DOS didn't reveal any problem. Windows again, the readings
and the disk accesses were correct until I ran again scandiskw. It messed it
again.
Try to make your hard disk partitioning as plain as possible. The worm
fix did obviously "repair" things it shouldn't have bothered with.
When I boot on another partition of the primary disk of the same computer
(the server), this disk if fine, scandisk works properly.
I could reinstall windows but I would prefer to repair it because of the
number of softs to re-install and the time to spend to retrieve the
originals.
Hm. I'll tell my opinion below.
2- Main computer problem:
There are crossed files in the FAT and one bad cluster: "the input of E:\Az
is incorrect, the first cluster od the directory input is invalid ..."
Only a 10 GB partition of this disk is concerned. This is the primary disk,
logical partition number 2.
Because of the total lack of control I have onto scandisk, I keep this
partition as is waiting to backup it.
As I said, there are several probable reasons for the ruined partition
table - the former presence of a disk drive manager, which doesn't run
any more but has some influence on the way the disk geometry is
organized internally, because it was "translated" by the driver, which
works the other way round, too, when the fdisk created a partition.
Second, there are two primary partitions, which are accessed on boot up
in an unusual way, which might cause the OS to be kind of "disoriented",
if it suddenly finds itself beyond the primary partition #1.
And there is yet another issue. At least the Win9x versions (I don't
know about the NT variants) don't like partitions that start/stop in the
midst of a cylinder (that is a stack of sector rings, located exactly
above or below each other, on different sides of the hard disk platters.
Think of it a a kind of bracelets of the same size, being stacked up).
Other OSes, mostly UNIces, can deal with that, but don't count on MS
products to tolerate such "breach of boundaries".
As I said the two HD problems appeared after fixnetsky was run on both
computers. It completed on the A7N8X and aborted on the server. The main
computer's log was correct, it didn't create any log on the server.
I'm completely convinced windows has been damaged during the scaning / virus
removal on the server.
This might well be, especially if the removal tool did more than it
should have done (perhaps someone suspected a boot sector component to
be present in the Netsky worm); but I don't know for sure what really
happened. As we Germans say: "You don't stick inside there"
Concerning the main computer, I'm afraid to repair the error due to the fact
scandisk might destroy the data.
Once I had a Win 3.1 that crashed my FAT in irregular intervals on a
Pentium 100, and so I bought a new mainboard, only to be able to
configure the shadow BIOS, to exclude certain areas. The hard disk was
attached to a very simple SCSI controller (with no proprietary BIOS),
which had caused the problem.
The disk geometry is a delicate thing, and MS products don't do much
more than tell the hard disk to do this and that, and if something goes
wrong, they can't compensate for the error.
If you are willing to take risks, you might try the Ranish Partiton
Manager and re-create the partition table with that (while the data are
meant to be still readable). But you must be very confident, that the
result will be exactly as you had set up the partitions before; as
Ranish will do what you tell it, no matter what, and whatever might come
from that.
I would prefer a complete low level re-organisation (format doesn't
really fit it), and build the hard disks anew. I know that this means
much work, but imagine the errors still lurking in the background and
suddenly raising their ugly heads, exactly when you need it least.
Gabriele Neukam
(e-mail address removed)
