Wszystko chodziło do czasu reinstalacji systemu, po tym fakcie mam regularne BSoD'y za każdym razem, jest to L1E62x64.sys , a przynajmniej tak wyniki z analizy minidumpów, aktualizacje/zmiany sterownika nie pomagają.
Kod:
Loading Dump File [C: \Users\Damian\Desktop\011111-14305-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c: \symbols*http: //msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`02a11000 PsLoadedModuleList = 0xfffff800`02c4ee50
Debug session time: Tue Jan 11 17: 18: 19.651 2011 (UTC + 1: 00)
System Uptime: 0 days 6: 24: 18.103
Loading Kernel Symbols
...............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck A, {8, 2, 0, fffff80002ff17f7}
Unable to load image \SystemRoot\system32\DRIVERS\L1E62x64.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for L1E62x64.sys
*** ERROR: Module load completed but symbols could not be loaded for L1E62x64.sys
Probably caused by : L1E62x64.sys ( L1E62x64+81f3 )
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ff17f7, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002cb90e0
0000000000000008
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ff17f7, address which referenced memory
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ff17f7, address which referenced memory
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ff17f7, address which referenced memory
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ff17f7, address which referenced memory
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002ff17f7, address which referenced memory
Z poziomu Menadżera urządzeń bym odinstalował kartę sieciową i uruchomił odnowa system aby znalazło ponownie nowy sprzęt, albo zainstalował sterownik od producenta karty sieciowej, ale również przed tym bym odinstalował obecny.
Wątpie czy to pomoże, ale wywaliłem sterownik i i uruchomiłem system tak jak mówisz. Wcześniej instalowałem sterownik ze strony producenta, jest znacznie nowszy od tego z Win7, a BSoDy były. Czekam na rozwój sytuacji.
Hej.
Mogę prosić Ciebie o plik minidump abyś mi przesłał i jeżeli możesz napisz mi jak najdokładniej o Twoim sprzęcie. Pytanie czy Twój system jest w wersji PL?. Dwa skąd masz system i czy jest legal nie torrent czy coś w tym rodzaju
Pzdr
Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)
Wszystko instalowane ze strony producenta lub najnowsze sterowniki jakie udało się znaleźć.
Dodam, że na Win7 przesiadłem się jakieś 7 miesięcy temu i wszystko było ok. Parę dni temu formatowałem OS, bo strasznie się zamulił, stwierdziłem, że szybciej pozbędę się problemu poprzez format. Jednak przez to zaczęły pojawiać się BSoDy. Formatowałem 2 lub 3 razy bo myślałem, że coś skopałem, ale zawsze było tak samo.
Hej.
Jeszcze jedno pytanie jaki masz program antykoncepcyjny na swoim kompie. Twój problem jest dość złożony i masz przerwanie na stosie. W pewnym momencie przekazuje dane na stos, ale później nie potrafi sobie poradzić. Czy robiłeś może overclocking?. Nie wiem czy znasz program Burn In Test. Jak coś pobierz go i zrób test nim i ustaw w programie na badane podzespoły 100% i zobaczymy czy wtedy coś wykryje.
Na razie takie moje sugestie. Aha podejrzewam, że nie zrobiłes nakładki na system tzn.,że instalowałeś z bootowania płyty?.
Pzdr
Jeszcze jedno pytanie jaki miałeś wcześniej system?. Czy dodawałeś jakieś podzespoły?.
Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)
(Ten post był ostatnio modyfikowany: 12.01.2011 21:42 przez bodziulla.)
Używam Aviry oraz Outposta. Wcześniej Win7 pracował stabilnie przez jakieś 7 miesięcy, gdy przetaktowałem E8400@3600Mhz, bez zmian napięć itd. Bardzo się zdziwiłem, gdy na nowo postawionym systemie, rzucał BSoDami. Instalacje systemu robiłem z płytki bootowalnej (zgranego wcześniej obrazu z MSDNAA).
System mam ciągle ten sam Win7 Pro 64bit PL. Oczywiście była czysta instalacja (format itd.) Od 7 miesiecy nic nie zmieniałem w podzespołach.
Ogólnie jak czytałem w zasobach internetowych to BSoD'y spowodowane sterownikami są dość łatwe do zlikwidowania, chodzi głównie o zmianę sterownika lub usunięcie jakiegoś programu.
Nie myślałem, że może to być spowodowane OC procesora, skoro wcześniej chodził szmat czasu bez żadnego BSod'u, czy choćby nawet się nie zawiesił przez 7 miesięcy!
_________________________________________________________________________________________________________________________________
Odpaliłem Burn In Test, przeprowadziłem testy RAM'u i procesora na standardowych taktowaniach no i PASSED.
(Ten post był ostatnio modyfikowany: 13.01.2011 10:51 przez FeXXer.)
Hej.
Odnośnie zmian w taktowaniu procka może on chodzić jakiś czas i będzie gut, ale potem się zbuntuje i koniec. Moim zdaniem nic nie wskazuje na sterowniki u Ciebie. Masz przerwanie na stosie i nie radzi sobie. Spróbuj ponownie wrócić do ustawień jak poprzednio i powinno pomóc. Również, jeżeli masz passed w Burn In Test czy możesz napisać jaki jest symbol błędu i czego dotyczy?
Pzdr
Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)
Zmieniłem taktowanie już dnia wczorajszego póki co nic złego się nie dzieje, dziwi mnie tylko fakt, że system nie daje rady na taktowaniu, które nominalnie było prawidłowe dla mojej konfiguracji. Programem sprawdzałem już po zmianach taktowania, więc błędów nie było jeśli o to chodzi. Mam nadzieje, że dobrze zrozumiałem pytanie
Hej.
Dokładnie o to mi chodziło. Praktycznie uważam, że teraz nie będziesz miał bsoda i dotyczył praktycznie Twojego przetaktowania. Nikt nie zauważył a raczej sugerował się tylko nazwą błędu, ale bsody czyta się całe. Tutaj było ewidentne przerwanie na stosie i nie dotyczyło to sterownika a błędu w systemie. Coś robiłeś na kompie Twój przetaktowany proc albo miał za mało napięcia lub co innego i nie mógł sobie radzić z poleceniem i powodował błędy na stosie a co za tym idzie polecenia, które były wysyłane z mostka S lub N powodowało utratę chwilową "myślową" i sobie nie radził i system kapitulował. Jeżeli mówisz, że teraz nie masz w Burn In Test błedów to świetnie. Poczytaj może na temat Twojego procka i jego możliwości przetaktowania, bo nie każda seria może być w takiej samej wysokości przetaktowana.
Pzdr
Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)
(Ten post był ostatnio modyfikowany: 14.01.2011 09:49 przez bodziulla.)
Dziękuje, widzę, że masz pojęcie o tym co piszesz Mój E8400 w rewizji E0 ma ponoć potencjał, a tak jak pisałem bez problemów radził sobie z 3,6GHz bez zmian napięć przy 1,24V na wcześniejszym systemie. Ja niestety pierwszy zacząłem analizować minidumpy jakiś tydzień temu, bo wtedy miałem pierwszego BSoD'a na Win7 Pro 64bit, a wcześniej nie było to potrzebne. Potrafię wyciągnąć tylko dane, które bezpośrednio wskazują na przyczynę problemu poprzez nazwę
Jeszcze tylko jedno pytanie, czy wiesz może co jest lepszym narzędziem diagnozującym stabilność RAM, czy memtest, czy może oprogramowanie podane przez Ciebie, które przemawia do mnie wygodą ?
(Ten post był ostatnio modyfikowany: 14.01.2011 12:53 przez FeXXer.)
Polecam obeznanie się z wątkiem: Testowanie pamięci RAM programem Memtest86+
Czyli po przywróceniu def taktów procka, BSOD ustąpił? Procek ma potencjał podkręcania, ale to nie sam procek jest kluczem do sukcesu. Może masz ustawioną zbyt duża wartość FSB, za duże takty pamięci ram, zasilacz nie utrzymuje napięć, temperatura.
Napisz jak jaką masz płytę główną i jak ustawiłeś FSB, mnożnik procka, taktowanie pamięci i jakie timingi.
Tak BSoD'y ustały. Pracuje teraz na 3GHz, FSB 333MHz, reszta AUTO
Płyta to Asus P5QL PRO, więc chyba nie jest źle.
FSB wcześniej było ustawione na 400MHz a mnożnik 9, więc na czysto 3,6GHz, reszta chyba AUTO Znajomy polecił, abym sprawdził, czy stabilnie będzie przy samej zmianie FSB, ze względu na możliwości procesora i tak właśnie było. Wiem, że na tej płycie mógłbym pewnie dojść do stabilnych 4GHz, przy odrobinie wsparcia i chęci.
Temperatury są na dobrym poziomie, nie przekraczają norm.
E8400 chłodzone SilentiumPC Spartanem, max 57-58*C (OCCT),
GPU Sparkle GTX 260-216core, też ma się dobrze tutaj max w grach to 75*C a furmark jakieś 87-88*C,
pamięci to 4 sztuki DDR2 A-Data Vitesta 1GB 1066MHz,
zasilacz to poczciwy Chieftec (GPS-450A), pamiętający czasy 18-stki jednak dobrze sobie radził przez ten cały okres i powinien mieć jeszcze mały zapas.
Chętnie bym przetaktował go na 4GHz, tylko potrzebuje małego wsparcia, sam czytając poradniki mam pewne obawy, że coś mogłem zrozumieć inaczej, albo pomylić opcje w BIOS'ie. A nie każda płyta główna oferuje takie same ustawienia w BIOS'ie.
Hej.
Pobierz sobie program CPU- Z i pokaż na screenie jaki masz model procka?.Zakładka CPU wskaże nam jaki masz model i wtedy można coś powiedzieć jak i na ile można wydolić z Twoim prockiem. Podaj też jaki masz bios
Pzdr
Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)
No nieźle, zwiększenie FSB i reszta na Auto nie wróżą sukcesu w OC Zwiększając FSB, zwiększają się takty pamięci Ram i timingi też pewnie poszły Ci w górę (większe timingi to gorzej). Musisz wszystko dobrze dopasować. O chłodzenie martwić się nie musisz. Jurto możemy posiedzieć nad OC.
Może samo zwiększanie FSB nie jest szczególnie zalecane, ale uwierz mi przez ostatnie pół roku, jeszcze przez reinstalem OS, miałem właśnie takie ustawienia, a PC był naprawdę stabilny, nie zanotowałem nawet 1 (słownie: jednego) zawieszenia systemu
Jutro, a w zasadzie już dziś będę miał trochę czasu, także nie ma problemu.
Sądzę, że można już bez przeszkód zamknąć wątek, bo zaczyna zmierzać w nieco inną stronę, a cel już został osiągnięty poprzez znalezienie przyczyny opisanego problemu.
(Ten post był ostatnio modyfikowany: 15.01.2011 00:48 przez FeXXer.)
Post: #1
Podziękowania od:
Mój E8400 w rewizji E0 ma ponoć potencjał, a tak jak pisałem bez problemów radził sobie z 3,6GHz bez zmian napięć przy 1,24V na wcześniejszym systemie. Ja niestety pierwszy zacząłem analizować minidumpy jakiś tydzień temu, bo wtedy miałem pierwszego BSoD'a na Win7 Pro 64bit, a wcześniej nie było to potrzebne. Potrafię wyciągnąć tylko dane, które bezpośrednio wskazują na przyczynę problemu poprzez nazwę 
