Re: BSOD i minidump

Użytkownik "szymek" <cacup@poczta.onet.pl> napisał w wiadomości
news:hj87o9$gop$1@nemesis.news.neostrada.pl...
> Wygląda mi na to ze BSODy wywołują losowe pliki. Myślę ze jakiś
> MemTest warto byłoby puścić, choć kości RAM nowe.

MemTest i jakiś test "burn-in" w sprzęcie. Ja kiedyś zapuściłem w lapku
test, gdzie program przez tydzień puszczał z procka dym, realizując
jakieś obliczenia, komputer wręcz parzył, a błędów zero.
Kości RAM... o ile takt mają dobry (niedawno po ponad pół roku
zorientowalem się, że mam złą geometrię dysku - nie startowala konsola
odzyskiwania, ale bezproblemowo startowal system... W BIOSie sie
przestawiło...
Jak zbadać dysk, podpowiem za chwilę.

>
> Zwróć proszę uwagę na mój post z końca ubiegłego roku:
> http://groups.google.com/group/pl.comp.os.ms-windows.winnt/browse_thread/thread/32490dfc5fcbccfb -
> od tego momentu sie coś zaczęło niedobrego dziać z tym moim lapsem.

No fakt, zajarzyłem.

>
> w skrócie, najpierw myslalem ze to HDD, potem pamięć RAM (okazało się
> że była walnięta), i potem sugestia o "jakims" uszkodzeniu płyty
> głównej. I chyba jednak wszystko na to wskazuje, że jest jakiś problem
> sprzętowy.

Takowoż, pamiętam problem (tak, to ja), opis sytuacji najbardziej
pasował... pasuje mi do problemow z HDD. Jak pisalem, problem mógł
spowodować, ze jakiś ważny plik uległ uszkodzeniu, na tyle perfidnemu,
że normalnie system funkcjonuje, dopiero w specyficznej sytuacji coś nie
zabangla, procek dostanie do wykonania spietruszony kod i się wywali.
Przeleć znów każdą z kości pamięci w każdym ze slotów, po minimum 3
cykle MemTest, a całe badanie, jak będziesz mieć czas (może być zrobione
etapami, w czasie przerw w pracy), zrób przynajmniej dwukrotnie,
wynotuj, która kość w którym slocie "błądzi", a która gdzie jest OK.
Następnie całość przynajmniej 3-4 cykle, także w 2 próbach, z pewnym
odstępem czasowym, np. pierwsza "na zimno", druga po jakiejś wysilonej
robocie (może to być burn-in test, dowolny) (ja w swoim lapku zrobilem
to przynajmniej po 10 razy... a i tak co innego się okazało).
Jeśli nie masz czasu, to każdą kość na 3 cykle w pierwszym porcie
pamięci. Całość, jeśli nie wypełnia wszystkich portów, to w tych o
najniższych numerach. Gdy wielkości kości różnią się, to mniejszą kość
do portu o niższym numerze. (oczywiście, chodzi o ilość RAM).
Jeśli masz możność, zaduś trochę procka, stawiając lapka na puchatym
kocu, doprowadzając do włączenia wiatraka, monitoruj temperaturę aby
utrzymywać ją poniżej górnej granicy i wtedy memtestem przynajmniej dwa
cykle, a nawet trzy, cały czas monitorując, choćby termometrem, czy
procek nie grzeje za mocno. Przepływ powietrza nie może zostać stłumiony
całkowicie.
Jest to upierdliwe i dość czasochlonne, ale czasem dopiero przy takim
teście "oliwa na wierzch wyplywa".

Zakladam, że test wypadł pomyślnie...
Dysk... jeśli masz miejsce, znajdź kilka(naście) największych plików w
układzie (Total Commander, ctrl-B i kolumna "wielkość"), wykonaj ich
kopie najlepiej na inny dysk, ale jak styknie miejsca, to i na tej samej
partycji. Ale, te kopie przygotuj w specjalny sposób. Każdy z plików (im
więcej, tym lepiej) kopiuj (najlepiej do oddzielnego, pustego katalogu)
osobno przez F5, następnie szybciutko klik na "w tle" i zadajesz do
kopiowania następny plik. Chodzi o to, aby jednocześnie, równolegle,
kopiowało się jak najwięcej plików z zawartością jak najwięcej
niezerowych i nie-FF bajtow, aby po prostu, kolejne bajty różiły się. im
bardziej bedzie szaleć pozycjoner w dysku, tym lepiej.
Po zakończeniu kopiowania wszystkich plików (system może mocno mulić w
tym czasie, nie uruchamiaj, jeśli nie trzeba, niczego, poza kopiowaniem
(TC, widzisz postępy każdego pliku)), każdą parę porównujesz, najlepiej
z okna wiersza poleceń
fc /b plik1 plik1-kopia
(podstawiasz oczywiście właściwe nazwy pary, pamietaj o przelączniku /b)
Powinno się zakończyć "nie stwierdzono różnic".
Metoda porównania (tym razem para po parze, w kolejce) bardziej
skomplikowana:
fc /b plik1 plik1-kopia >> wynik
Tu także podstawiasz nazwy z pary, a wynik możesz mu dać nazwę jaką
chcesz, byle różną od badanych.
Pamiętaj, aby dziobki były dwa - z jednym zawartość pliku "wynik" jest
nadpisywana, a z dwoma nowa treść jest dopisywana do istniejącej.
kolejne pary zadajesz
fc /b plik2 plik2-kopia >> wynik
a po przeleceniu wszystkich odczytaj zawartość pliku "wynik", jeśli
wszystkie rezultaty będą "nie stwierdzono różnic", to dobrze.

Kolejna próba - z dowolnych plików wybierz pewną porcję, zapamiętaj w
jakiś sposób wybór - akcję powtórzymy kilka razy z takim samym wyborem -
Total Comamnder, paker ZIP (ten wybierz), kompresja... jaka będzie, aby
była, ja daje największą (9). Spakuj 5 razy tę paczkę, w tym momencie
nawet wskazane by było, aby jak najwięcej innych programów w miarę
intensywnie korzystało z systemu, po pakowaniu sprawdź po pierwsze, czy
wielkości paczek są identyczne, po drugie, czy przy sprawdzaniu CRC nie
było komunikatu o błędnej sumie (nawet jeden taki komunikat, to niemal
na pewno potwierdzenie, że sprzęt kuleje), po trzecie, czy zawartości
plików zgadzają się, czy są identyczne. Miałem kiedyś uszkodzenie, że
dla jednej paczki rożne były komunikaty o błędzie CRC, różne długości
archiwów, różna ich zawartość bajtowa (która niekiedy dała sie z
powrotem rozpakować)... prawdopodobnie od lekkiego padnięcia kości RAM.
Aż dziw, że system się prawie nie wywracał, Win98SE. Niech archiwa będą
duże, co zwiększy prawdopodobieństwo wystąpienia błędu i załapania sie
go i ujawnienia. Pilnuj tylko, aby wolnego na partycji nie zmalało
zbytnio (empirycznie stwierdzone, że Winda nie musi lubić spadku poniżej
64MB), choć jak w tym czasie nie będą pracować inne programy, to w
najgorszym razie pakowanie zbyt dużej paczki skończy się komunikatem o
braku miejsca, a niedokończone archiwum zostanie automatycznie
skasowane. Chodzi o to, aby żadnemu z programów nie zabrakło miejsca na
dysku poza twoją kontrolą.

Możliwe braciszku, że namordujesz sie z tym nieziemsko, ja wiem z
własnego doświadczenia, jak wredne potrafią być takie uszkodzenia. Fajno
by było, gdybyś miał możność przypięcia innego dysku i zainstalowania na
nim systemu, a następnie poużywania go przez tydzień, dwa (możesz
przekłądać dyski, byle ostrożnie, jeśli w międzyczasie komp będzie
potrzebny do czegos), o ile jednak się da, niech praca będzie ciagła,
bez przerw na wyłączenie. Jeśli tym razem nie będzie BSoD-ów, to
najprawdopodobniej zacieśniliśmy obszar poszukiwań. Mnie to, jak już
pisałem, wygląda na perfidne uszkodzenie dysku, niewyłapywalne zwykłą
diagnostyką, ani badaniem SMART. Miałem tak, podmieniłem dysk i błędy
ustąpiły jak ręką odjął.

Tyle ode mnie, lecę kimać, pytaj, gdyby coś było niejasne.

-- 
Pająk chwat,
wszystkich brat!