Skocz do zawartości

Losowo pojawiające się blue screeny


muad

Rekomendowane odpowiedzi

Witam,

zacznę od samego początku...

od pewnego czasu pojawiają się mi blue screeny, z początku pojawiały się one tylko podczas grania. Zacząłem wiec poszukiwanie problemu w konfiguracji, sterownikach, testowaniu pamięci, niestety nic nie znalazłem. System chodzi deflautowo - bez żadnego podkręcania. Następnie podniosłem napięcie ramu z 1,65 do 1,7, wówczas podczas grania było ok, natomiast blue screeny pojawiały się losowo gdy była włączona przeglądarka. Dodam jeszcze, że zaraz po złożeniu pc testowałem wydajność na różnych "podkręceniach" i wszystko działało bdb.

 

Następnie za pomocą verifier zweryfikowałem sterowniki inne niż microsoft, wówczas podczas ładowania ok. kilka sekund po pokazaniu się pulpitu pojawiał się blue screen i tak w kółko (w crash dump pojawiały się m.in. dxgmms1.sys, ntoskrnl.exe, dxgkrnl.sys, HIDCLASS.SYS, luafv.sys), musiałem w trybie awaryjnym zdezaktywować verifier. Następnie zacząłem weryfikować w ten sposób pojedynczo kolejne sterowniki, zauważyłem że za każdym razem jedna pozycja zmienia nazwę. Stąd moje obawy czy to nie jest jakiś ukrywający się pasożyt. Różne skanery jednak nic nie wykryły. Dodam, że mam win 7 64bit pro (w wersji oem - pisałem też do ms ale oemowcom nie pomagają). Od złożenia komputera w maju 2010 roku nie było żadnych problemów. A i jak chciałem uruchomić aswmbr to od razu pojawił się blue screen. Nie wiem już gdzie szukać problemu i czy to wina sprzętu czy jakiegoś wirusa.

OTL.Txt

Extras.Txt

Odnośnik do komentarza
Pomoc jest darmowa, ale proszę rozważ przekazanie dotacji na utrzymanie serwisu: klik.

Przy diagnostyce BSOD przydatne są analizy zrzutów pamięci. Widzę, że w zainstalowanych programach masz "Debugging Tools", to pytaniem jest dlaczego nie zaprezentujesz tu dokładnych wyników z debugera.

 

 

od pewnego czasu pojawiają się mi blue screeny, z początku pojawiały się one tylko podczas grania

 

To raczej nie nasuwa skojarzeń z infekcją. Przypuszczalnie problem pojedzie do działu Hardware.

 

 

natomiast blue screeny pojawiały się losowo gdy była włączona przeglądarka. (...) A i jak chciałem uruchomić aswmbr to od razu pojawił się blue screen.

 

Prędzej to ewentualnie może narzucać takowe skojarzenie, ale sprawcy i tak wąsko selekcjonowani. Na systemach 64-bitowych infekcja prowadząca do BSOD powinna mieć charakter natywnie 64-bitowy (by mogła w ogóle coś zdziałać na tak wysokim poziomie), a to redukuje zagadnienie tylko do rootkitów w MBR (nie jest mi znana żadna inna infekcja o charakterze "natywnym" tworząca bypass weryfikacji, a 32-bitowe infekcje to nie ten poziom wykonawczy). W kwestii programu aswMBR, to nie jest on do końca sprawny na systemach 64-bitowych. Bardziej przyjacielski jest Kaspersky TDSSKiller i jeśli chcesz zweryfikować na potencjalną obecność bootkitów, to właśnie nim. Z pewnością pokaże u Ciebie jedną rzecz - sterownik SPTD od wirtualnych napędów, co należy oczywiście zignorować.

Osobiście mocno powątpiewam tu w koncepcję infekcji.

 

 

PS. ComboFix zapuszczałeś a nie ma o tym ani słowa ani prezentacji wyników. Poza tym, nie licz na niego za bardzo na platformie x64.

 

 

.

Odnośnik do komentarza

Dziękuje za odpowiedź,

 

wieczorem dołącze zrzuty z debbugera. Kaspersky i TDSSKiller także zapuszczałem i także nic nie wykryły (poza sterownikiem od napędów wirtualnych). Też obstawiam raczej problem ze sprzętem i najprawdopodobniej z ramem. Zastanawia mnie tylko dlaczego gdy za pomocą opcji verifier weryfikowałem sterowniki były błędy - chyba dokończe pojedyńcze weryfikowanie sterowników.

 

Czy gdy pamięć ram ma błędy i testowana jest za pomocą memtestu to za każdym razem program pokzauje błąd? I jak długo musi chodzić test, aby mieć pewność że wszystko jest ok, ja najdłużej miałem załączony memtest przez godzinę. Czy faktycznie trzeba każdą kość testować osobno - przecież i tak trzeba odesłać komplet, więc chyba nie ma znaczenia która kość jest uszkodzona (mam dwie kości dual ram).

 

Odnośnie combofix, gdy podejrzewałem infekcję w necie poczytałem o nim i faktycznie zapuściłem go (dopiero później trafiłem na te forum i poczytałem sobie o tym kiedy go uruchamiać), combofix zrobił skan po restarcie gdy tworzył raport komputer się zawiesił i raport nie powstał.

Edytowane przez Landuss
Temat zostaje przeniesiony do Hardware
Odnośnik do komentarza

Moim zdaniem problem z pamięcią. Tyle tylko, że nie musi chodzić o pamięć RAM. Chętnie zobaczę S.M.A.R.T. dysku twardego. Podaj pełną konfigurację sprzętową kompa, to napiszę jeszcze jak sprawdzić kartę graficzną i zobaczymy, czy nie ma jakichś znanych konfliktów.

Czy gdy pamięć ram ma błędy i testowana jest za pomocą memtestu to za każdym razem program pokzauje błąd?

Przy bardziej poważnych błędach tak, ale zdarzają się też jakieś subtelne błędy, które występują tylko w pewnych okolicznościach i z nimi jest problem, bo memtest86+ może ich w ogóle nie wychwycić.

I jak długo musi chodzić test, aby mieć pewność że wszystko jest ok, ja najdłużej miałem załączony memtest przez godzinę.

Rozsądne minimum to jakieś 3 godziny/kość. Najlepiej jednak taki test zostawić na noc.

Czy faktycznie trzeba każdą kość testować osobno - przecież i tak trzeba odesłać komplet, więc chyba nie ma znaczenia która kość jest uszkodzona (mam dwie kości dual ram).

I tak i nie. Niekiedy jeśli testujesz kości razem, to pewne błędy są pomijane, więc należy sprawdzić kości pojedynczo. Z drugiej strony przetestowanie kości pojedynczo nie wyłapie błędów spowodowanych przez złe sparowanie kości pracujących w dual channel. Jeśli masz czas, to warto sprawdzić kości na wszelkie sposoby.

 

[edit]

Tu była głupota.

Edytowane przez Sevard
Odnośnik do komentarza

Witam,

załączyłem 3 zrzuty z debbugera i smart głównego dysku, co do konfiguracji to:

AMD Phenom II 955 BE

Asus M4A89GTD Pro

2 x 2GB 0CZ 7-7-7-20 (1.65V) 1333 Mhz

Radeon 5770 Powercolor 1GB

Seagate Barracuda SATA 2, 500 GB

LG 227WT, OCZ 600W ModXStream PRO

Opera, Windows 7 64 bit pro

 

dodam jeszcze, że wszystko chodzi standardowo bez podkręcania.

dump1.txt

dump2.txt

dump3.txt

post-1535-0-21286200-1297365423_thumb.jpg

Odnośnik do komentarza

S.M.A.R.T poproszę z innego programu (np. HDD Scan, czy Crystal Disk Info), bo HDD Health nie pokazuje kolumny Raw data.

 

Niestety nie masz symboli debugowania, więc analizy małych zrzutów są niekompletne, ale z tego co widać BSOD jest powodowany przez jakiś sterownik, który nie jest zgodny z systemem. Czy zanim pojawił się problem podłączałeś coś? BSOD jest związany z plikiem hidclass.sys, a więc z urządzeniami interfejsu HID. Czyli do sprawdzenia są myszki, klawiatury, dżojstiki, klawiatury itp. działające pod USB. Błąd może być jednak spowodowany również przez coś innego.

Ten konkretny typ błędu C9 ma taką przyczynę:

The caller has changed the status field of an IRP it does not understand. (IRP specified.)

Źródło

Nie jest to błąd krytyczny, więc teoretycznie wystarczy zmienić ustawienia w czymś, co po angielsku nazywa się Driver Verifier Manager, ale to raczej jest wyjście ostateczne.

Odnośnik do komentarza

Zamieniłem kable sata dodatkowo zamieniłem wtyczki zasilające i kabel zasilający także, napięcia niestety nie mogę zmierzyć nie mam odpowiedniego miernika (tylko taki od 12 v do 250 v).

 

Na benchmark.pl w recenzji znalazłem:

 

" Na linii 12V odnotowałem spore odstępstwo od napięcia nominalnego. Jak pisałem wcześniej mieści się to w granicznych 5% normy ale warto zaznaczyć o tym podbiciu. Dochodzi do tego jeszcze fakt, że napięcie skacze w zależności od obciążenia, skok o 0,05V. Wszystko dalej mieści się w normie ale trzeba fakt ten zaznaczyć. Na liniach 5V i 3,3V zasilacz radzi sobie już lepiej, choć napięcia dalej nie są równe nominalnym i lekkie skoki przy różnym obciążeniu. Nie są to jednak tak wyraźne skoki jak w przypadku linii 12V."

 

Nie wiem czy to istotne bo mieści się w normie.

post-1535-0-89163100-1297373361_thumb.jpg

Odnośnik do komentarza

Heh. Recenzja dotyczy recenzowanego egzemplarza i nie może przewidzieć tego jak zachowują się wszystkie zasilacze w danej serii. Innymi słowy w każdej serii znajdzie się i lepsze i gorsze egzemplarze. OCZ MXS to generalnie dosyć solidne zasilacze (choć wrażliwe na wysokie temperatury), ale to nie oznacza, że Sirtecowi (rzeczywisty producent tego zasilacza, OCZ tylko przykleja swoją nalepkę) nie mogła się przydarzyć jakaś wpadka.

No niestety, ale bez miernika się nie da porządnie sprawdzić zasilacza. Obserwuj w takim razie Wartość RAW w wierszu p ID równym BC. Jeśli będzie się zwiększała, to daj znać.

Odnośnik do komentarza

Zainwestowałem w miernik i zmierzyłem napięc

12,29

5,07

3,40

12 zmieniała się ok. 0,01 w dół i górę i to w ciągu minuty dużo razy, 5 było stabilne 3,3 trochę się zmieniało między 3,39 a 3,40. W stresie z kolei wszystkie napięcia były bardziej stabilne, rzadziej się wartości zmieniały. Poczyściłem sobie trochę komp, ponowie przeinstalowałem sterowniki i od tego czasu jak wywala blue screen to tylko przez win32k.sys i ntoskrnl.exe oraz taki ciąg 0xc0000005. Skanowałem memtestem ponad 3h na razie dwie kości razem i było ok.

Niemniej zauważyłem jeden dziwny problem odinstalowałem stery od grafiki i chciałem dać starego catalista ale sterownik karty graficznej się nie zmienił (ręcznie we właściwościach go usuwałem) poza tym nie chce mi się otworzyć Catalist Control Center. Poza tym teraz blue screen wyskakuje dużo później tak po 1h grania a wcześniej po ok. 20 minutach.

Odnośnik do komentarza

Dziś obniżyłem taktowanie pamięci do 1066 Mhz i okazało się, że (jak na razie) blue screeny się nie pojawiają, z tego wynika iż to wina pamięci. Sprawdzę jeszcze każdą kość osobno jak będę miał czas. Niemniej jednak gdyby memtest nie znalazł błędów to czy mogę na podstawie tylko obniżonego taktowania reklamować pamięć? Oczywiście 1333 7-7-7-20 1,65V to parametry z opakowania.

Odnośnik do komentarza

Być może po zluzowaniu timingów będzie działać dobrze, niemniej jednak skoro producent daje dane parametry to nie po to ludzie kupują sprzęt aby ustawiać niższe wartości. Wcześniej wszystko działało ok, wiec wydaje mi się że zmiana biosu nie powinna wpłynąć pozytywnie, ale na wszelki wypadek uaktualnię. Z drugiej strony - skoro (marekW) piszesz, że ta płyta główna kapryśna odnośnie pamięci - to czy można mieć w 100 % pewność, że niestabilność jest winą płyty lub błędów pamieci. Przed zakupem pamięci sprawdzałem czy są one kompatybilne na stronie asusa i te pamięci są ok. W sumie jak lekko obniżę timingi i będzie ok to i tak na wydajności niewiele powinienem stracić.

Odnośnik do komentarza

Producent podaje kompatybilność z modułami ale nie wiadomo kiedy bazę uaktualniał, stąd sugestia o aktualizacji biosu. Drugie to producenci niejako się czasem chwalą "ostrymi" timingami ale niekoniecznie to co jest wypisane na etykiecie a tym co zapisane w SPD jest w zgodności, dlatego była prośba o wrzucenie do posta "pikczersów" z CPU-Z z zakładek, które wspominałem.

Odnośnik do komentarza

Mam tylko wcześniejsze zrzuty, po uaktualnieniu biosu nie pojawił się blue screen, system się zawiesił i wymusiłem reset. A odnośnie tabeli timingów z (cpu-z) przy 609 Mhz wyświetlane jest 8-8-8-19, 666 Mhz się nie wyświetla. Czy ten program dobrze czyta te dostępne ustawienia, o ile pamiętam w Evereście wygląda to całkiem inaczej. Teraz mam ustawione 9-9-9-24 (sama płyta tak ustawiła jak dałem na auto) i jest jak na razie ok.

Odnośnik do komentarza

CPU-Z sczytuje faktyczny zapis w kości spd modułu, chociaż bywa tak, że ustawienie w biosie auto (inna nazwa to "by spd") nie zawsze jest stabilne i trzeba co nieco poprawić. W kwestii timingów jest kilka możliwości, można np. ustawić "luźne" z możliwością obniżenia napięcia V lub "zaostrzyć" (nawet do takich które w spd nie są zapisane tzn standard jedec lub epp ich nie obsługuje) ale w tym wypadku jest konieczne podniesienie napięcia, to zaś jest równoznaczne z podniesieniem temperatur modułów. Everest nie pokazuje chyba wszystkich zapisów, bardziej dokładny jest CPU-Z, zresztą projekt "everest" upadł i teraz jest to znów AIDA64, ale nawet i on/a nie pokazuje wszystkiego co w spd jest. Tak jak pisałem być może masz Command Rate ustawione na 1T i tu może być problem z ustawieniem "ostrzejszych" timingów, gdyby tak było to ustawienie na 2T daje możliwość ustawienia mniejszych wartości timingów. Możesz się bawić, ale jeśli teraz jest stabilnie to możesz przy takich ustawieniach pozostać, możesz też sprawdzić w tym evereście w testach (pierwsze cztery od góry) jak jest lokowana wydajność wg. innych konfiguracji.

Odnośnik do komentarza

Po przestawieniu Command Rate na T2 system działa stabilnie ale i tak pojawił się blue screen niemniej dopiero po 2 godzinach w stresie (ustawienia miałem 7-7-7-20). Zwiększyłem teraz timingi i dalej będę testował. Na razie dokładnie nie sprawdzałem wyników testów wydajności pamięci ale na oko dużej różnicy nie ma. Dzięki za wskazówki.

Edytowane przez picasso
3.04.2011 - Po upływie sporego czasu i braku dodatkowych komentarzy temat uznany za zamknięty. //picasso
Odnośnik do komentarza
Gość
Ten temat został zamknięty. Brak możliwości dodania odpowiedzi.
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...