Newsgroup: it.comp.os.win.win9x
Titolo: Bits a caso sul mio PC

Cerco aiuto ed idee per diagnosticare un problema pazzesco che ho sul
sistema.
Ogni mese, nella mia lucida follia, faccio un po' di manutenzione.
Tra l'altro faccio un giro di SFC per verificare se i programmi sono
tutti a posto.
Questa volta SFC mi segnala che alcuni moduli non sono come li aveva
visti l'ultima volta.
Salto le fasi intermedie per arrivare alle conclusioni: ad ogni lettura
dalla RAM Windows mi vede dati diversi, alzando a caso il quinto bit
dell'ultimo byte di un gruppo di 16.
Ecco un esempio.
Due esecuzioni successive dello stesso comando, a distanza di pochi
secondi, dentro una finestra DOS di Windows:
A:\>fc /b c:\windows\system\iconlib.dll a:\icbk12.dll
Confronto dei file c:\windows\system\ICONLIB.DLL e a:\icbk12.dll in
corso...
00005BCF: FF F7
0000B69F: FF F7
0000B6AF: FF F7
0000B6DF: F7 FF
0000BF9F: F7 FF
0000C51F: F7 FF
0000F6FF: FF F7
0000F70F: FF F7
0001005F: 77 7F
A:\>fc /b c:\windows\system\iconlib.dll a:\icbk12.dll
Confronto dei file c:\windows\system\ICONLIB.DLL e a:\icbk12.dll in
corso...
0000389F: F7 FF
0000B69F: F7 FF
0000B6AF: FF F7
0000B6DF: F7 FF
0000BF9F: F7 FF
0000C51F: F7 FF
0000F6FF: FF F7
Si noti che la seconda esecuzione non ha comportato una lettura fisica,
perche' i dati erano in cache.
La stessa operazione effettuata poco dopo, in DOS puro:
A:\>fc /b c:\windows\system\iconlib.dll a:\icbk12.dll >a.txt
Confronto dei file c:\windows\system\ICONLIB.DLL e a:\icbk12.dll in
corso...
FC: nessuna differenza riscontrata.
Il contenuto di entrambi i files, preso su un'altra macchina, e':
003880  ff ff ff ff 70 00 00 00 00 00 00 8f ff ff ff f7
003890  ff ff ff ff 70 00 00 00 00 00 00 8f ff ff ff f7
0038a0  ff ff ff ff 70 00 00 00 00 00 00 8f ff ff f7 77
Riassumendo e aggiungendo ulteriori dettagli:
- in DOS puro la lettura e' corretta
- in Windows (anche in modalita' provvisoria), i dati risultano alterati
- programmi diversi (Frhed, Winbrowse, Compara, FC) segnalano differenze
- cambiando l'hard disk (cassetto estraibile) il problema rimane
- un test approfondito sulla RAM (Troubleshooter) non ha segnalato
errori
- copie successive dello stesso oggetto su un floppy producono risultati
diversi (confrontati su un altro PC)
- Windows ('98 prima edizione) sta funzionando allegramente senza
manifestare alcun disturbo
- MB ASUS A7V133 con AMD Duron 800 e 128Mb di RAM
- perche' ho usato SFC ? Vivevo cosi' bene nell'ignoranza.
- perche' mi sono dato all'informatica ?
In mezzo a questo disastro, gia' mi sarebbe di grande aiuto riuscire a
capire se e' un problema software o hardware.
:-(
--
Beppe
Firenze
g.sa...@katamail.com

 sistema.
[...]

 operazione con il debug di windows e un dump, tanto per scrupolo.
Debug ?
Dump ?
Con Windows '98 ?
Come funzionano ?
Dove sono documentati ?
--
Beppe
Firenze
g.sa...@katamail.com

 - MB ASUS A7V133 con AMD Duron 800 e 128Mb di RAM
Siamo sicuri che non sia il bug del Southbridge 686B?
Hai installato gli ultimi VIA4in1?
Ciao,
Pamela

 Hai installato gli ultimi VIA4in1?
Ci ho pensato.
Pero' il bug del 686B si manifesta durante il trasferimento di una
grande mole di dati, mentre nel mio caso i files sono di dimensioni
modeste.
Poi, se ricordo bene, la configurazione a rischio e' quando sul
controller sono montati due dispositivi, e nel mio caso ce n'e' uno
solo.
Infine l'errore arriva quando c'e' traffico di dati in lettura da un
disco ed in scrittura sull'altro, e nel mio caso c'e' solo lettura.
Ma quello che (credo) elimina ogni dubbio e' che, come si vede
dall'esempio, la seconda volta non c'e' lettura da disco da solo da
cache. Quindi (credo) il bit incriminato va 'on' in occasione di un
trasferimento dati da memoria a memoria.
Comunque i 4in1 sono 4.32
Voglio provare a chiedere sul forum specifico della A7V...
Grazie.
--
Beppe
Firenze
g.sa...@katamail.com

 Voglio provare a chiedere sul forum specifico della A7V...
Se non lo conosci già, dai anche un'occhiata al sito:
http://www.a7vtroubleshooting.com/
Ciao,
Pamela