Статия: Сините екрани (BSoDs)

Aquarius · Декември 15, 2012

Още самото прочитане ме наведе на хардуерният проблем с дънната платка, нещо което не може да се заключи от дъмповете, ако строго изхождаме от това какво се дава като проблемен драйвер. Дъното е 100% проблемно, като примерът беше нещо средно като показателно, че не винаги дъмповете сами по себе си са ползотворни...

Естествено, че от извадките не може да се определи каква е точно хардуерната причина. Затова в статията съм написал следното нещо, което е крайно съществено:

"Като заключение на хардуерната част бих искал да кажа, че има още няколко варианта за сини екрани. Това например са подутите кондензатори по дъното. Много е добре да си огледате дъното, особено в близост до цокъла на процесора за подути кондензатора и ако има такива да се вземат мерки. Това включва подмяна на кондензаторите като е добре всички кондензатори, които са от същия тип като надулите се да се подменят. В краен случай може и само всички кондензатори на съответната линия, но този вариант е по-лошия."

Е, проблемът е решен. След смяна на 20-тина кондензатора по дънната платка и Underclock на процесора...Явно е, че това дънце нисък клас толкова си може и толкова му е живота, та пътува към отвъдното, но колкото-толкова...

Така е, особено, когато става въпрос за стари дъна с обикновени електролитни кондензатори навсякъде из дъното. За щастие новите дъна от нисък клас имат полимерни кондензатори поне за захранващата схема на процесора, където натоварването е по-голямо, а една идея по-високия клас са с изцяло полимерни кондензатори (макар и не супер качествени), което значително им увеличава живота спрямо по-старите (и създава някои други проблеми, макар при специфични условия), но все пак не трябва да се забравя, че винаги има външни фактори, които указват влияние като типичен пример е качеството на подаваното напрежение от захранващия блок т.е. дали се вписва в ATX стандарта като пулсации в изходните напрежения примерно под 120mV на +12V линията както и дали регулацията е в норма.

Хубаво, че си се справил с проблема и дано ремонтът да не е по-скъп от цената на цялото дъно, защото това е често срещно явление в ситуации като тази.

P.S.: Обнових темата да покрива и Windows 8, макар че нещата са същите с изключение на новата опция Automatic memory dump и новия дизайн на сините екрани.

mailsss · Януари 12, 2014

ПОМОООООООЩ чисто нов лаптоп Packard Bell се рестартира когато му кефне - има моменти по няколко часа работи без проблем и после се появяват едни черти и се рестартира. Ето информацията от Memory.dmp - Моля за съдействие - нищо не разбрах от написаното във файла.

................

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck FC, {fffffa8006f6419a, 8000000218a009e3, fffff800718277e0, 3}

Page 20abc5 not present in the dump file. Type ".hh dbgerr004" for details

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+34580 )

Followup: MachineOwner

---------

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)

An attempt was made to execute non-executable memory. The guilty driver

is on the stack trace (and is typically the current instruction pointer).

When possible, the guilty driver's name (Unicode string) is printed on

the bugcheck screen and saved in KiBugCheckDriver.

Arguments:

Arg1: fffffa8006f6419a, Virtual address for the attempted execute.

Arg2: 8000000218a009e3, PTE contents.

Arg3: fffff800718277e0, (reserved)

Arg4: 0000000000000003, (reserved)

Debugging Details:

------------------

Page 20abc5 not present in the dump file. Type ".hh dbgerr004" for details

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xFC

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

DPC_STACK_BASE: FFFFF8007182DFB0

TRAP_FRAME: fffff800718277e0 -- (.trap 0xfffff800718277e0)

NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.

rax=6a15a217bc2a27db rbx=0000000000000000 rcx=fffffa8006f6419a

rdx=085131481131482e rsi=0000000000000000 rdi=0000000000000000

rip=fffffa8006f6419a rsp=fffff80071827978 rbp=fffff80071827ab0

r8=0000000000000000 r9=0000000000000000 r10=fffffa8006f6419a

r11=00000000f2861bfe r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei pl nz na po nc

fffffa80`06f6419a 2e483111 xor qword ptr cs:[rcx],rdx cs:0010:fffffa80`06f6419a=000000001131482e

Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800725facd6 to fffff80072469240

STACK_TEXT:

fffff800`71827618 fffff800`725facd6 : 00000000`000000fc fffffa80`06f6419a 80000002`18a009e3 fffff800`718277e0 : nt!KeBugCheckEx

fffff800`71827620 fffff800`725fa584 : fffff800`71820000 fffff800`724931dd fffffa80`0a6cc5e0 ffffffff`fffcf2c0 : nt! ?? ::FNODOBFM::`string'+0x34580

fffff800`71827660 fffff800`724a3e2b : fffff800`72709f00 fffff800`71827700 fffffa80`0668a99e fffff800`718277e0 : nt! ?? ::FNODOBFM::`string'+0x3334a

fffff800`718276a0 fffff800`72466cee : 00000000`00000008 fffff800`72709f00 fffff800`71827800 fffff800`718277e0 : nt!MmAccessFault+0xa8b

fffff800`718277e0 fffffa80`06f6419a : fffffa80`068031e3 fffff800`726a2bc0 fffff800`7240f000 00000000`00000f44 : nt!KiPageFault+0x16e

fffff800`71827978 fffffa80`068031e3 : fffff800`726a2bc0 fffff800`7240f000 00000000`00000f44 00000000`00000000 : 0xfffffa80`06f6419a

fffff800`71827980 fffff800`726a2bc0 : fffff800`7240f000 00000000`00000f44 00000000`00000000 00000000`00000286 : 0xfffffa80`068031e3

fffff800`71827988 fffff800`7240f000 : 00000000`00000f44 00000000`00000000 00000000`00000286 fffff800`72491ac1 : nt!EtwpGroupMasks

fffff800`71827990 00000000`00000f44 : 00000000`00000000 00000000`00000286 fffff800`72491ac1 08513148`1131482e : nt!`string' <PERF> (nt+0x0)

fffff800`71827998 00000000`00000000 : 00000000`00000286 fffff800`72491ac1 08513148`1131482e fffff800`00000002 : 0xf44

STACK_COMMAND: kb

FOLLOWUP_IP:

nt! ?? ::FNODOBFM::`string'+34580

fffff800`725facd6 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+34580

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 51316195

IMAGE_VERSION: 6.2.9200.16548

BUCKET_ID_FUNC_OFFSET: 34580

FAILURE_BUCKET_ID: 0xFC_nt!_??_::FNODOBFM::_string_

BUCKET_ID: 0xFC_nt!_??_::FNODOBFM::_string_

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xfc_nt!_??_::fnodobfm::_string_

FAILURE_ID_HASH: {a715e467-86e4-97ce-e0a9-37223e080980}

Followup: MachineOwner

---------

B-boy/StyLe/ · Януари 12, 2014

Според дъмп-а или е проблем с някой драйвър или с паметта.

Пробвайте в търсачката на Windows да въведете msconfig => enter => services => сложете отметка пред Hide all Microsoft services => Apply. След това отидете до Startup и временно премахнете всички отметки и натиснете Apply. Рестартирайте и тествайте дали ще се появи проблема.

Ако да, тогава тествайте и за "лоши" драйвъри по-следния начин: (първо направете нова точка на възстановяване)!!

В търсачката на Windows въведете - Verifier => натиснете Enter.
Изберете Create custom settings (for code developers) => натиснете Next, изберете Select individual settings from a full list.
Сложете всички отметки без Low Resources simulation
Натиснете Next и изберете Select driver names from a list
Кликнете на колонката Providers за да ги подредите по производител.
Сложете отметки пред всички драйвъри за които не участват Microsoft Corporation, Nvidia, Advanced Micro Devices, Macrovision Corporation, (и всички започващи с името dump)
Натиснете Finish и рестартирайте компютъра.
Ако компютъра откаже да стартира нормално, влезте в Safe Mode (натискайте F8 многократно при рестарт), изберете менюто Safe Mode, след това изберете Start => въведете System Restore => върнете точката за възстановяване, която създадохте по-напред в инструкциите.
Като заредите нормално, отворете Start => въведете CMD => натиснете Enter.
В конзолата въведете командата: verifier /reset и рестартирайте за да изключите проверката на драйвърите.
Ако по време на проверкара на драйвърите се стигне до син екран, архивирайте новите файлове в папката C:\Windows\Minidiump и качете архива на хостинг по-избор.

Публикувайте линк за download в следващия си коментар.

Тествайте и за следните неща:

Пуснете една проверка за лоши сектори:

В търсачката на Windows въведете CMD => кликнете върху файла CMD.exe и изберете Run as administrator => напишете CMD.exe => въведете командата:

chkdsk c: /x /f /r => натиснете Enter

Съгласи се с Y на диалоговия прозорец.
Рестартирайте компютъра и би трябвало проверката да започне.
След това вижте какви са били резултатите.

Рапорта от проверката ще намерите тук:

Start => в полето за търсене въведете eventvwr.msc => applications => събитие WinInit Event ID 1001
Kопирайте рапорта в следващия си пост.

Пуснете и проверка за прецакани системни файлове:

Въведете в търсачката на Windows CMD => кликнете върху файла CMD.exe и изберете Run as administrator => напишете CMD.exe => въведете командата:

sfc /scannow => натиснете Enter

findstr /c:"[sR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt" => натиснете Enter

След това прикачете лог файла sfcdetails.txt, който ще се създаде на десктопа в следващия си коментар.

За тестване на РАМ паметта може да опитате с Memtest86+ 5.1
Разархивирайте архива и запишете ISO файла с Burnaware например за да се получи буутващ диск с опцията Burn Image

http://i.imgur.com/FoXIo71.png
След това направете от БИОС-а CD/DVD устройството да е първото стартиращо устройство и направете проверка на РАМ паметта.
Ако теста е успешен не би трябвало да има грешки:

http://3.bp.blogspot.com/-djhfllttviQ/UFvPhCjAz1I/AAAAAAAABB4/QanedPyL7_g/s1600/Memtest86+1.png

За да сте напълно сигурни, че РАМ-а е ок е добре да оставите теста за през нощта за поне едно 8-10 часа и още по-добре извадете всички плочки и оставете само една и ги тествайте една по една.
Ако бъдат открити грешки ще видите грешки в червен фон подобно на тези:
http://billy-oneal.com/forums/memTest/memtestFail.png

и ще се наложи да посетите сервиз (или да смените проблемната плочка).

Разбира се процесора и видеокартата също могат да се тестват, но засега толкова.

Успех!

mailsss · Януари 13, 2014

WOW ... Благодаря за изчерпателните и пълни обяснения!

Като направя всичко ще пиша! Понеже съм с Уиндоус 8 - тайно се надявам да е някой счупен драйвер ...

Много благодаря!

4u4k0To · Април 9, 2014

Здравейте,

ще ми дадете ли отговор/съвет на една моя питанка относно УинБозата Седем?

Малко предистория :

Преди много години си купих iPod classic пето поколение с обем от тридесет гигабайта дисково пространство. Намерил съм му много полезни приложения, дори и за преносим твърд диск. Първоначално го ползвах на старата ми щайга (ПЦ) с УинБоза еКСПи, но след като си купих Мак, предпочетох да е форматиран под Мак ОС - поради съображения за сигурност. За да го използвам на стационарния компютър си инсталирах МакДрайв Осем. До тук всичко си е наред!

Към средата на миналата 2013-та година купих на родителите си преносим компютър (отново ПЦ), та с него имам големи ядове. Сложих му Седмица ОС-ма 32бита, въпреки че е предназначен за Осмица 64бита. Имах известни проблеми в началото с несъвместимост на драйверите, както и да е де... оправих се някак си - за момента е перфектен. Сигурно ще ме питате, откъде съм ги теглил - от официалния сайт на еЧПи. Та на това ПЦ също съм инсталирал същата версия МакДрайв, по същата причина като на моята щайга. Когато закача въпросния айПод, софтуерът го разпознава като Епъл хардуер и си върша нещата. Но от едно известно време насам преносимия краш-ва. Излиза син екран с някаква грешка, започва да зарежда Бозата, пита ме дали го пусна под сейв мод или по нормалния стандартен начин и прочие. Зарежда Бозата, като през това време не съм изваждал плейър-а от ЮеСБи-то. Когато се опитам отново да прехвърля нещо от едното устройство на другото историята пак се повтаря, потретва и т.н. Не ми позволява да премахна айПод-а или пък камо ли да изключа компютъра по нормалния начин. Питам се: "Да не е случайно вирус?" Стартирам АВП-то Каперски Пюр 3.0 да сканира и двата вида хардуер - 'е няма такова чудо-вище! Добре де... все пак дори и да има заразен файл, нали по време на прехвърлянето от Мак-а на плейър-а ще забележа, че нещо не е наред или има някакъв файл в повече - вирус? Имам и преносим твърд диск с обем от четвърт терабайт, на който съм инсталирал Мак ОС (защото... дълга история, да не навлизам в още излишни подробности). Предполагам за всички Ви това е позната история, когато има даден проблем. С него нямам никакви ядове и на двете ПЦ-та с Бозица. Единствено те възникват само с айПод-а, когато го закача на компютъра на родителите ми - това е!

'Ей на, миналият петък (07.03. дъмп файл 01) бе последния път, когато отново направи срив системата и пак син екран, случи се когато се опитах да разкача плейър-а от ЮеСБи-то "по безопасен начин". Пропуснах да спомена, че преди да синхронизирам двете устройства, направих цялостен ъпдейт на компютъра (софтуер, драйвери, флаш плейър и прочие). Рестартирах, закачих айПод-а, прехвърлих файловете на ПЦ-то, реших да разкача и... без коментар. Ето ги дъмп файловете (MEMORY.DMP), който качих ТУК за 01 , ТУК за 02 , ТУК за 03 и ТУК за 04 . Опитах се да го отворя и софтуера windbg, каза : ТОВА . Направих Ви, няколко шота като тествах компонентите на машината. Файлът е .zip и се казва "process failed", ето го тук отдолу.

Сърдечно благодаря предварително за всички, които ще се отзоват на помощ!

Поздрави!

process failed.zip

Joll1Roger · Април 23, 2014

Забележка: За Windows 7 е задължително в регистъра HKLM\System\CurrentControlSet\Control\CrashControl да се създаде DWORD запис AlwaysKeepMemoryDump със стойност 1 (необходим е рестарт)

Причината за промяната на тази настройка е, че стандартно Windows XP създава т.нар. Small Memory Dump, който представлява само сегментът от паметта, в който е възникнала грешката. В резултат на това той е крайно недостатъчен за пълноценен анализ на срива. Kernel опцията предлага най-добро съотношение като полезна информация / обем тъй като записва разделът от физическата памет, използван от ядрото в момента на срива. А това са реално данните, от които имаме нужда при анализ тъй като паметта на процесите не ни интересува, защото те се изпълняват в потребителски (непривилегирован) режим на процесора и няма как да причинят директен срив и BSOD.

Здравейте колеги.Периодично ме мъчи един син екран изпълних горните указания и в момента имам MEMORY.DMP с големина 8gb и минидъмп 280кб.Къде може да бъркам?

Благодаря

Night_Raven · Април 23, 2014

Задал си Complete memory dump вместо Kernel memory dump.

5etleto · Декември 23, 2017

Здравейте. След заспиване на компа ми, при събуждане излиза син екран. Моля Ви за помощ.

............................

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

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 kernel debugger is available get stack backtrace.

Arguments:

Arg1: fffff8a00b225410, memory referenced

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000001, value 0 = read operation, 1 = write operation

Arg4: fffff880032acade, address which referenced memory

Debugging Details:

------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800034af100

GetUlongFromAddress: unable to read from fffff800034af1c8

fffff8a00b225410 Paged pool

CURRENT_IRQL: 2

FAULTING_IP:

klflt+1ade

fffff880`032acade 48890a mov qword ptr [rdx],rcx

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: avp.exe

TRAP_FRAME: fffff88006c0cf40 -- (.trap 0xfffff88006c0cf40)

NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.

rax=0000000000000000 rbx=0000000000000000 rcx=fffffa800d9a33e0

rdx=fffff8a00b225410 rsi=0000000000000000 rdi=0000000000000000

rip=fffff880032acade rsp=fffff88006c0d0d8 rbp=fffff88006c0d1b0

r8=fffffa800d9a3370 r9=00000000000000fd r10=0000000000000000

r11=fffff880032b5e20 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei pl zr na po nc

klflt+0x1ade:

fffff880`032acade 48890a mov qword ptr [rdx],rcx ds:fffff8a0`0b225410=0000000000000000

Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800032719e9 to fffff80003272440

STACK_TEXT:

fffff880`06c0cdf8 fffff800`032719e9 : 00000000`0000000a fffff8a0`0b225410 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx

fffff880`06c0ce00 fffff800`03270660 : 00000000`00000000 00000980`00000000 0000007f`fffffff8 fffffa80`10c94802 : nt!KiBugCheckDispatch+0x69

fffff880`06c0cf40 fffff880`032acade : fffff880`032acbeb fffffa80`0d9a3370 fffffa80`10c94802 00000000`00000000 : nt!KiPageFault+0x260

fffff880`06c0d0d8 fffff880`032acbeb : fffffa80`0d9a3370 fffffa80`10c94802 00000000`00000000 fffff880`00e070cf : klflt+0x1ade

fffff880`06c0d0e0 fffffa80`0d9a3370 : fffffa80`10c94802 00000000`00000000 fffff880`00e070cf 00000000`00000000 : klflt+0x1beb

fffff880`06c0d0e8 fffffa80`10c94802 : 00000000`00000000 fffff880`00e070cf 00000000`00000000 fffff880`032b9e28 : 0xfffffa80`0d9a3370

fffff880`06c0d0f0 00000000`00000000 : fffff880`00e070cf 00000000`00000000 fffff880`032b9e28 00000000`00000000 : 0xfffffa80`10c94802

STACK_COMMAND: kb

FOLLOWUP_IP:

klflt+1ade

fffff880`032acade 48890a mov qword ptr [rdx],rcx

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: klflt+1ade

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: klflt

IMAGE_NAME: klflt.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 52949624

FAILURE_BUCKET_ID: X64_0xD1_klflt+1ade

BUCKET_ID: X64_0xD1_klflt+1ade

Followup: MachineOwner

---------

This free analysis is provided by OSR Open Systems Resources, Inc.

Want a deeper understanding of crash dump analysis? Check out our Windows Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)

Crash Code Links

View the MSDN page for DRIVER_IRQL_NOT_LESS_OR_EQUAL

Search Google for DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hide DivInformation About Address 0xfffff8a00b225410

Supplied dump is a mini-dump. Memory analysis commands unavailable.

.................................

И това:

..................

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)

A driver has failed to complete a power IRP within a specific time (usually 10 minutes).

Arguments:

Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp

subsystem.

Arg2: 0000000000000258, Timeout in seconds.

Arg3: fffffa800d782660, The thread currently holding on to the Pnp lock.

Arg4: fffff80000b9a3d0, nt!TRIAGE_9F_PNP on Win7

Debugging Details:

------------------

Implicit thread is now fffffa80`0d782660

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

DRVPOWERSTATE_SUBCODE: 4

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800032db762 to fffff800032d8cca

STACK_TEXT:

fffff880`037ee0c0 fffff800`032db762 : fffffa80`0d782720 fffffa80`0d782660 00000000`00000000

00000000`00000000 : nt!KiSwapContext+0x7a

fffff880`037ee200 fffff800`032ddf8f : fffffa80`0f10da20 fffff880`037ee418 fffff8a0`00000000

00000000`00000000 : nt!KiCommitThreadWait+0x1d2

fffff880`037ee290 fffff880`01d6fc0e : 00000000`00000000 00000000`00000000 fffff8a0`00e94f00

00000000`c0000500 : nt!KeWaitForSingleObject+0x19f

fffff880`037ee330 fffff880`01d692cf : fffffa80`11523190 00000000`00000002

00000000`00000000 fffff880`01d2d101 : ndis! ?? ::LNCPHCLB::`string'+0x4f4b

fffff880`037ee3c0 fffff880`01d4f552 : fffffa80`00000000 00000000`00000000 fffffa80`0d831c00

fffffa80`1144e060 : ndis!ndisPnPNotifyAllTransports+0x18f

fffff880`037ee530 fffff880`01d4f520 : fffffa80`0d8389d0 fffffa80`113621a0 fffffa80`0d831c80

fffff880`037ee620 : ndis!NdisFNetPnPEvent+0xd2

fffff880`037ee570 fffff880`01d4f520 : fffffa80`0d831c80 fffffa80`113621a0 fffffa80`1054c520

fffff880`037ee620 : ndis!NdisFNetPnPEvent+0xa0

fffff880`037ee5b0 fffff880`01d1b508 : fffffa80`1054c520 00000000`00000000 fffffa80`113621a0

00000000`00000002 : ndis!NdisFNetPnPEvent+0xa0

fffff880`037ee5f0 fffff880`01d86d2a : 00000000`00000000 fffffa80`0d873c60

00000000`00000000 fffffa80`113621a0 : ndis!

ndisDevicePnPEventNotifyFiltersAndAllTransports+0x128

fffff880`037ee6f0 fffff800`0353ee01 : fffffa80`0d98bbd0 fffffa80`11362050 fffff880`037ee848

fffffa80`1144e060 : ndis!ndisPnPDispatch+0x80b

fffff880`037ee790 fffff800`036bd021 : fffffa80`1144e060 00000000`00000000 fffffa80`0da5ad90

fffff880`037ee828 : nt!IopSynchronousCall+0xe1

fffff880`037ee800 fffff800`036bb848 : fffffa80`1148f640 fffffa80`1144e060 00000000`0000030a

00000000`00000308 : nt!IopRemoveDevice+0x101

fffff880`037ee8c0 fffff800`036bcb67 : fffffa80`0da5ad90 00000000`00000000

00000000`00000003 00000000`00000086 : nt!PnpSurpriseRemoveLockedDeviceNode+0x128

fffff880`037ee900 fffff800`036bcc80 : 00000000`00000000 fffff8a0`033dcd00 fffff8a0`0e840410

fffff880`037eea58 : nt!PnpDeleteLockedDeviceNode+0x37

fffff880`037ee930 fffff800`0375a54f : 00000000`00000002 00000000`00000000

fffffa80`111ac010 00000000`00000000 : nt!PnpDeleteLockedDeviceNodes+0xa0

fffff880`037ee9a0 fffff800`0375b10c : fffff880`037eeb78 fffffa80`0dcd6000 fffffa80`0d782600

fffffa80`00000000 : nt!PnpProcessQueryRemoveAndEject+0x6cf

fffff880`037eeae0 fffff800`036442f6 : 00000000`00000000 fffffa80`0dcd60a0 fffff8a0`033c8b30

00000000`00000000 : nt!PnpProcessTargetDeviceEvent+0x4c

fffff880`037eeb10 fffff800`032e0839 : fffff800`0353dc68 fffff8a0`033dcde0 fffff800`034802d8

fffff800`034802d8 : nt! ?? ::NNGAKEGL::`string'+0x46e5b

fffff880`037eeb70 fffff800`0357229a : 00000000`00000000 fffffa80`0d782660

00000000`00000080 fffffa80`0d76e720 : nt!ExpWorkerThread+0x111

fffff880`037eec00 fffff800`032c86e6 : fffff880`03572180 fffffa80`0d782660 fffff880`0357cfc0

00000000`00000000 : nt!PspSystemThreadStartup+0x5a

fffff880`037eec40 00000000`00000000 : fffff880`037ef000 fffff880`037e9000 fffff880`037ee410

00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:

ndis! ?? ::LNCPHCLB::`string'+4f4b

fffff880`01d6fc0e 8b5e28 mov ebx,dword ptr [rsi+28h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: ndis! ?? ::LNCPHCLB::`string'+4f4b

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ndis

IMAGE_NAME: ndis.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 561c7ad7

FAILURE_BUCKET_ID: X64_0x9F_4_ndis!_??_::LNCPHCLB::_string_+4f4b

BUCKET_ID: X64_0x9F_4_ndis!_??_::LNCPHCLB::_string_+4f4b

Followup: MachineOwner

.....

Това е системата ми

Предварително благодаря.

Night_Raven · Декември 23, 2017

Според първия файл на разтоварване проблемът най-вероятно е причинен от драйвър на продукт на Kaspersky. Според втория файл проблемът най-вероятно се дължи на вграден в Windows драйвър. Следователно е напълно възможно продуктът ти на Kaspersky да създава проблеми или някой драйвър на хардуерен компонент се дъни.

Ако продуктът на Kaspersky, който използваш, не е последна версия, те съветвам да го актуализиращ. Най-добре като първо премахнеш текушия. Ако обаче е последна версия, можеш да опиташ да го деинсталираш и да видиш как ще се държи системата.

Другата ми препоръка е да се увериш, че всички останали драйвъри са актуални версии. С оглед на това, че използваш морално и технологично остаряла операционна система като Windows 7, подозирам, че и драйвърите за хардуерните ти компоненти са стари.

Всъщност, говорейки за Windows 7, защо по дяволите използваш тази операционна система на хардуера, с който разполагаш? Не знам дали да се смея или да плача...

seriallnumber · Ноември 30, 2022

Перфекна статия без никакви забележки браво

Статия: Сините екрани (BSoDs)

Препоръчан пост

Link to comment

Сподели другаде

ТОП потребители в тази тема

Популярни дни

ТОП потребители в тази тема

Популярни дни

Popular Posts

Night_Raven

Night_Raven

Публикувани изображения

Link to comment

Сподели другаде

Link to comment

Сподели другаде

Link to comment

Сподели другаде

Link to comment

Сподели другаде

Link to comment

Сподели другаде

Link to comment

Сподели другаде

Link to comment

Сподели другаде

Link to comment

Сподели другаде

Link to comment

Сподели другаде