Susan said:
My mom lives alone and does not have anyone fooling with the computer. I do
not believe this is malware related. I found the following post on Dell
http://en.community.dell.com/forums/t/19283543.aspx
and it was the same computer model and occured this month so I tried to
reset the CMOS but the problem still exists.
I had changed Drive 1 and Drive 2 to On prior to the reset so I know that
there was a change after doing the reset.
When I went into the setup after the reset, the Drives showed the following:
Drive 0: On
Drive 1: Off (the factory default is On)
Drive 2: Off (the factory default is On)
Drive 3: On
OnBoard Devices
USB Controller
On (the factory default is On)
There have been no hardware additions/replacements to mom's computer. We
opened the case for the first time to reset the CMOS today. I have also
called McAfee and asked if there was anyway the Total Protection could
change the BIOS settings and was told no!
Any suggestions? Thanks
Susan
Well, that's a puzzle for sure.
Clearing the CMOS, should be detected by the BIOS on the next POST,
and the BIOS should load defaults. And a normal value for defaults,
should be to enable those ports. (Note as well, whatever is doing
this, drive 1 and drive 2 are on different interfaces, so this
is more clever than it seems.)
So, you're saying it is impossible to turn on Drive 1 and Drive 2 ?
As far as I know, the BIOS should not "react" to the state of
drives on the cable, except to choose to recognize them or not.
So if a drive was defective, the BIOS should continue to keep
the drives enabled, but it may show no device is detected there.
Disabling an entry in the BIOS, is supposed to be up to the
human operator. There is no reason for the BIOS to flip them
off.
What happens, if you unplug the ribbon cable from the motherboard,
for say the second drive (Drive 2 and Drive 3 would be on that
cable) ? Does the behavior change at all ? Can you make any
changes to those settings, which "stick" between boots ?
I would probably try the following test cases
1) Enter the BIOS and enable Drive 2 and 3. "Save and exit". Wait
for the BIOS to start again, press F2 and reenter the BIOS.
Are the drives still enabled ? This test case, is to see if the
BIOS is doing this on its own.
2) Enter the BIOS and enable Drive 2 and 3. "Save and exit".
Boot with a non-Windows CD, that is, if the CD can be enabled
at all. When you're finished with the disc, pop it out of the
tray, and do a reboot. Enter the BIOS again by pressing F2.
Has the setting changed while the non-Windows OS was running ?
3) Enter the BIOS and enable Drive 2 and 3. "Save and exit".
Boot WinXP. When done, do a reboot. Enter the BIOS again
by pressing F2. Has the BIOS reverted to the disabled settings
on Drive 2 and Drive 3.
If you need something else to boot from, that could be a Linux LiveCD,
or even a hard drive test diagnostic from the likes of Seagate or
Western Digital. You need something, other than the WinXP C: drive
to boot from, so you can compare the results, to the test case
where you boot WinXP. I think memtest86+ is available in CD form,
and that one boots its own little environment. To burn an ISO9660
CD, you need a burner program like Nero, or some other tool that
knows how to parse an ISO file. (You don't just "copy" the file
to the CD - the file is like a set of instructions on how to
burn the CD, such that it is bootable.)
http://www.memtest.org
It is possible for software in the OS, to ignore a "disable" setting.
For example, ATI video cards with AGP interfaces, have driver code
to ignore the AGP setting in the BIOS. But your situation is the
other way around, where it would appear that something is changing
the BIOS. The CMOS settings are protected by a checksum, so whatever
is doing it, would also have to be clever enough to recompute the correct
checksum and put that back. That is not difficult to do technically,
as the whole thing is documented. What I don't know, is what
protection mechanisms exist to prevent monkey business like that.
If only the WinXP booting case causes the problem, I'd probably
do a malware scan. For example, this is a self-contained virus
scanner. It boots its own copy of Linux. Once booted, it goes out
to the network, and fetches the latest virus definitions. And
then it does a scan. It is an example of a tool that allows
scanning, without WinXP running. There is less the malware can
do in that case, unless the malware was designed to infect
multiple OSes (which is possible, but more work for the
malware writers).
http://dnl-eu10.kaspersky-labs.com/devbuilds/RescueDisk/
To use that, I'd have my regular network setup, all working
in Windows first. Then shut down, and reboot with the
Kaspersky bootable CD in the drive. Since the network
would still be enabled when Linux starts running, that
should make it easy for the DHCP agent in Linux, to
enable networking on the Ethernet interface, so that
the virus definitions can be updated.
If you had a complete failure of your optical drives,
and could not boot from them at all, the next alternative
would be USB flash devices as a boot option. But,
you have to be a certified rocket scientist to get
that to work reliably for each case you want to run.
Preparing CDs is a lot easier.
This isn't likely to be caused by a bad CMOS battery
(CR2032 coin cell battery), as in the above test
cases, you're not turning off the PC power, and so
the CMOS is supplied from +5VSB output of the power
supply. So even if the CMOS battery was weak, there
should still be a solid 3V level being delivered to
the Southbridge CMOS power input.
Paul
)