copied file different than original

[Jean-Marc Ranger]

Short problem description:
When performing the following operations:
copy c:\i386\drivers.cab c:\temp\tempfile
fc /b c:\i386\drivers.cab c:\temp\tempfile
Instead of getting "no differences encountered", I get
(as an exemple)
0EF141ED: 0C 91
0EF141EE: 68 4D
0EF141EF: 00 47
0EF141F0: 00 36
0EF141F1: 0C 3D
0EF141F2: 68 71
0EF141F3: 00 C5
0EF141F4: 00 13

So computer is untrustable - any data file could get
corrupted !!!


Configuration:
NEC Versa DayLight E120 256MB/20GB
Win XP Pro reinstalled a few hours ago from NEC recovery
CD.
SP1A installed from a network drive
Update Rollup installed from a network drive
All security patch installed from windows update.
Some recommended patches installed (list available)
Other software installed:
Acrobat reader 5 (from NEC applications CD)
Macromedia flash (current version)

Tests performed:
- Scanned for virus with a recent copy of AVG. Found
nothing.
- Scanned hard drive with scandisk. Found nothing.
- Scanned hard drive with Hitachi diagnostic software.
Found nothing.
- Scanned for memory defects with microsoft's mtinst.exe
for 12 hours. Found nothing.
- Reinstalled from NEC recovery CD. Problem absent.
Problem comes back while reinstalling software and using
the computer for a while. Configuration described above
is the "smallest" application set that was nocticed with
the problem. At other times, larger software sets were
demonstrated as "clean" - problem wasn't there.
- Rebooted computer numerous times... No help.

Other notes on that software set:
- I had to try 3 times to successfully install the last
critical update (I don't have the number handy, but it's
225KB is size).


History:
Problem was first noticed while downloading Linux CD-Rom
images from the Internet. These images come with md5
checksum files. MD5 validation failed.
A second download from the same site gave the same result
(invalid MD5), but with different checksums !!! This
means that download results are both unusable, but both
files are different.

Other comments:
- comparing two times the same pair of files always lead
in the same differences being reported. I guess that the
bug happens on "write", not on "reads".
- When the problem is there, it's always there (it always
happen at least once in, say, three copies of
drivers.cab). When it's not (after reinstalling with NEC
CD), it's never there (I can perform 20 copies without
ever seeing the issue).
- To this point, I've wiped the HD three times, and I got
the trouble three times within a week of reinstalling.
The fourth time, I had to reinstalled due to XP failing
to boot reporting a corrupted windows\system32
\config\software file. I don't think this is related.
- Also (this is weird) there seems to be constant
patterns on the differences between copies:
-- differences are always in blocks of either 4- or 8-
bytes long. There may be more than one diference "block"
between two files
-- differences always start on address ending in ....1ED
-- on every diff block, one of the two files contains
either 0C 68 00 00 or 08 68 00 00 or 04 68 00 00 (four
bytes, read from top to bottom). If the diff block is 8-
bytes, the pattern is repeated.
-- these constant patterns did "survive" XP
reinstallations. Every time the problem pops-up, these
patterns are there.


I can't even tell if this is software or hardware. I'd
guess it's software, but triggered by a border-line
hardware.

NEC offered to replace the motherboard on RMA, so I'll
have to turn the computer in within a few days. But in
the mean time, I'm able to do tests.

Ideas, anyone ?

Reply at "jmranger _at_ iquebec _dot_ com"

Thanks



Here are other differences as they were captured by a
test batch file.
-------------------------
Comparing files C:\I386\DRIVER.CAB and 1
007281ED: FF 04
007281EE: 97 68
007281EF: 3A 00
007281F0: B5 00
007281F1: FA 08
007281F2: D7 68
007281F3: 1F 00
007281F4: F7 00
-------------------------
Comparing files C:\I386\DRIVER.CAB and 3
009691ED: 45 04
009691EE: 51 68
009691EF: 74 00
009691F0: 6F 00
009691F1: 77 08
009691F2: 62 68
009691F3: CB 00
009691F4: 2D 00
-------------------------
Comparing files C:\I386\DRIVER.CAB and 1
009DD1ED: 0C 00
009DD1EE: 68 00
009DD1EF: 00 02
009DD1F1: 0C 80
009DD1F2: 68 A1
009DD1F3: 00 18
009DD1F4: 00 32
-------------------------
Comparing files C:\I386\DRIVER.CAB and 2
009DD1ED: 00 0C
009DD1EE: 00 68
009DD1EF: 02 00
009DD1F1: 80 0C
009DD1F2: A1 68
009DD1F3: 18 00
009DD1F4: 32 00
00A221ED: 00 0C
00A221EE: 9E 68
00A221EF: 4B 00
00A221F0: ED 00
00A221F1: 96 0C
00A221F2: D8 68
00A221F3: 40 00
00A221F4: F3 00
-------------------------
Comparing files C:\I386\DRIVER.CAB and 1
046F81ED: C6 0C
046F81EE: 74 68
046F81EF: 0A 00
046F81F0: BD 00
046F81F1: 78 0C
046F81F2: DD 68
046F81F3: 58 00
046F81F4: 2E 00

 

[Jean-Marc Ranger]

Ok, some more info on this (continuing Jan 8 post)

Bug still unresolved, but scope is narrowed.

I tried repeating the test using an external USB2 hard
drive. Here's what I found:

source_loc......dest_loc......success
......................................
internal........internal......no...(we already knew that)
internal........external......yes
external........external......yes
external........internal......yes

So my trouble is only present when both reads and writes
happen on the internal drive. Speed issue ??? Read on.

Since this is a SpeedStep-equipped laptop (P3-800 LV I
think), I decided to play with various power schemes.
Here, I hit the jackpot. Bug is present in all schemes
but two:
- Home/Office Desk
- Always On

I decided to go one step further, and downloaded
SpeedSwitchXP, which is supposed to allow exact control
on SpeedStep mode. Here, bug is present only in "dynamic
switching" scheme. "Max performance", "battery
optimized" and "max battery" are working fine.

This begins to really look like stack corruption during
interrupt processing, or something like that.

So Microsoft people, are you listening ? I really don't
think I can go much further without your help.

Jean-Marc Ranger