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

Aquarius · Август 1, 2010

http://pics.softvisia.com/design/pics/11650/01.png

I. Kакво представлява "синият екран" и какви са причините да се появи?

(ъъъм...син екран с бели букви? Не баш...)

Синият екран се визуализира в резултат на изпълнението на системната функция KeBugCheckEx, която от своя страна се изпълнява при какъвто и било системен срив. Това, което прави KeBugCheckEX, основно включва маскиране на всички прекъсвания на процесора(ите), превключване на графичната подсистема в режим VGA на ниска резолюция и визуализиране на синия екран и стоп кода.

Но, за да се изпълни KeBugCheckEx, както вече стана ясно, трябва да се появи системен срив. Възможните сривове, които могат да причинят изпълнение на въпросната функция, което ще генерира син екран са:

Драйвер или функция на операционната система, причиняващи необработваемо изключение (Unhandled exception), като например нарушение при достъп до паметта.
Драйвер или функция на операционната система, които изрично извикват KeBugCheckEx, тъй като засичат вътрешни условия показващи, че системата не може да продължи изпълнение без риск от повреда на данни.
Хардуерни проблеми, като например дефектирал компонент (памет, диск и др.).

Именно честата поява на сини екрани под Windows, при средния потребител, кара някои видни „експерти” да смятат, че Windows е 2^512 пъти по-нестабилна операционна система спрямо друга известна OS, започваща с „L” примерно. За съжаление ще разочаровам тези хора, тъй като статистиката сочи, че около и над 70% от всички сини екрани са причинени от драйвери на трети производители и само около 5% от грешки в кода на Microsoft. Останалата част са в резултат на хардуерни проблеми. Веднага ще дам яснота защо се получава така: драйверите, било то драйвери на хардуерни устройства или драйвери, използвани от софтуерни продукти за реализиране на определена функционалност (например филтриращи драйвери на файловата система, използвани от антивирусните продукти), са пример за код, който се изпълнява в kernel mode или иначе казано привилегирован режим на процесора (Ring 0). Това ниво на изпълнение предоставя права за цялата системна памет и всички инструкции на процесора. В природата на Windows NT-базираните операционни системи (NT/2K/XP/2K3/Vista/7) e това, че операционната система не предоставя никаква защита за компоненти, изпълняващи се в системен (привилегирован) режим. Иначе казано, попадне ли в системен режим, кодът има пълен достъп до паметта в системното пространство и може да заобиколи механизмите за сигурност с цел достъп до различни обекти, включително до всички данни на операционната система. Именно затова е изключително важно какъв код се изпълнява в системен режим за стабилността на системата. Точно тук идва проблемът, че тъй като Windows е най-популярната и използвана операционна система то броят на драйверите от трети производителите, които са потенциални кандидати да причинят BSOD е много, много по-голям спрямо тези за другите операционни системи. Можете да си представите каква е вероятността една машина с Windows да стигне до системен срив (BSOD) спрямо същата с друга по-слабо популярна OS, за която има в пъти по-малко потенциално нестабилни драйвери. Но за това не е виновна самата операционна система технически, а хората които пишат драйвери. Поради този проблем Microsoft съществува WHQL и подписването на драйвери. Тази стъпка има за цел да ограничи изпълнението на некачествен код в системен режим, което може да доведе до BSOD. За целта, когато се инсталира неподписан драйвер, операционната система, на база настройките на потребителя, може да изведе съобщение или изобщо да блокира инсталацията на неподписани драйвери. Последното е характерно за x64 изданията на Windows Vista/7, които стандартно не допускат изпълнение на неподписани драйвери. Разбира се, драйвер, който не е подписан не винаги значи, че е нестабилен както и обратното, но все пак един WHQL драйвер срещу някаква beta или пък модифицирана версия от съмнителен източник, е далеч по-вероятно WHQL драйверът да е по-стабилен, но винаги има и изключения.

Хардуерните проблеми са другият основен източник на сини екрани. Тук няма какво толкова да се каже, ясно е, че при некоректно работещ хардуер няма как да се очаква стабилност от страна на операционната система и в това число липса на сини екрани. Само бих искал да кажа, че към хардуерните проблеми влизат и некадърно направения оувърклок (прекалено агресивни настройки), както и проблемите с температурите на компонентите (особено през лятото), които две неща обикновено се пренебрегват от потребителите. Например една памет, която се държи на свръх високо напрежение за 24/7 работа е съвсем нормално да деградира с времето в резултат на което да почнат да се появяват сини екрани. Или пък ако се ползват прекалено агресивни тайминги в комбинация с висока честота, на която паметта не може да работи стабилно. И все пак тези причини обикновено са далеч по-редки, тъй като оувърклок обикновено се предприема от по-напреднали потребители. Проблемът с охлаждането е доста по-често срещан тъй повечето потребители подценяват охлаждането на компонентите като например избират евтини, некачествени кутии, които не са в състояние да осигурят възможност за адекватен въздушен поток и съответно правилно охлаждане на цялата система. И разбира се, класическите случай на дефектирал компонент също не са рядкост.

Най-малък е процентът от сини екрани, причинени от грешки в кода на Microsoft. За справяне с тези проблеми, Microsoft имат пуснати специални актуализации, които решават проблема. Като цяло, за да се гарантира стабилна работа на операционната система, едно от най-важните условия е тя да е обновена напълно, което означава последният Service Pack (ако има такъв) и всички допълнителни актуализации.

II. Какво да правим при поява на син екран?
(...моментален рестарт от копчето, бърз начин за побеждаване на синия екран.)

Стандартният съвет на повечето хора е да се запише съдържанието на синия екран и по-специално т.нар. стоп-код и после да се търси по него в интернет за информация как евентуално да се реши проблемът. Това не е най-лошата идея на света, но понякога не е особено ефективна и техники, като например да се извърши базов анализ на файла с извадка от паметта с помощта на инструмента WinDbg, дават значително по-добри резултати. Отделно има случай когато самият син екран предоставя достатъчно информация и съвети за решаване на проблема. Ще разгледаме и двете ситуации.

Първото нещо, с което ще започнем, е конфигурирането на системата, така че да може да видим самия син екран. Това се налага, тъй като стандартно Windows е конфигуриран да се рестартира автоматично при поява на син екран, след като запише файла с извадка от паметта. Точно тук идва тънкият момент, че при Windows XP стандартно системата създава т.нар. Small memory dump, който е изключително малък по размер и се записва толкова бързо, че реално не може да се види (системата изглежда, че се рестартира спонтанно). При Windows Vista/7 настройката по подразбиране е друга и там все пак имаме възможност за няколко секунди да погледнем съдържанието му. Най-добрият вариант е да се изключи опцията за автоматично рестартиране, за да може потребителят спокойно да прочете съдържанието на синия екран. Това става по следния начин при Windows XP, Windows 7 и Windows 8.x:

Windows XP

1) Отворете System Properties чрез десен клик върху My Computer и избиране на Properties от контекстното меню.

2) След като се отвори прозорецът System Properties изберете таба Advanced.

http://pics.softvisia.com/design/pics/11650/02.PNG

3) В секцията Startup and Recovery кликнете върху бутона Settings.

http://pics.softvisia.com/design/pics/11650/03.PNG

4) В появилия се прозорец Startup and Recovery е необходимо да премахнете отметката пред етикета Automatically restart в секцията System failure и да потвърдите настройките чрез кликване на бутона ОК.

http://pics.softvisia.com/design/pics/11650/04.PNG

Windows 7

1) Отворете System Properties чрез десен клик върху Computer и избиране на Properties от контекстното меню.

2) В прозореца System кликнете върху бутона Advanced system settings.

http://pics.softvisia.com/design/pics/11650/05.png

3) В секцията Startup and Recovery кликнете на бутона Settings.

http://pics.softvisia.com/design/pics/11650/06.png

4) В секцията System failure махнете отметката пред етикета Automatically restart и потвърдете чрез натискане на бутона ОК.

http://pics.softvisia.com/design/pics/11650/07.png

Windows 8.x

1) Отворете System Properties от Control Panel->System and Security->System или натиснете Win + X и от менюто изберете System.

2) В прозореца System кликнете върху бутона Advanced system settings.

http://i.imgur.com/53jvn.png

3) В секцията Startup and Recovery кликнете на бутона Settings.

http://i.imgur.com/OrY38.png

4) В секцията System failure махнете отметката пред етикета Automatically restart, ако по някаква причина не е избран Automatic memory dump то от падащото списъчно поле го селектирайте него (или Kernel memory dump, двете са еквивалентни, виж бележката по-долу!), след това потвърдете чрез натискане на бутона ОК.

http://i.imgur.com/mE9Jp.png

При Windows 8 положението е абсолютно еквивалентно с това при Windows 7 с тази разлика, че в падащото списъчно меню фигурира още една допълнителна опция (стандартно избраната), която се казва Automatic memory dump и на практика също генерира Kernel memory dump с тази разлика, че ако е избрана тя (Automatic) и размерът на файла за странициране на виртуалната памет (Pagefile.sys) е конфигуриран да бъде "System Managed" (както е стандартно), то Pagefile-ът ще има минимален размер, който е достатъчно голям да поеме Kernel Memory dump, което варира в зависимост от това в какво състояние е системата т.е. колко заредени драйвери има в момента, колко памет драйверите са алокирали от системната памет (Paged Pool/ NonPaged Pool) и други. Идеята на този нов режим в комбинация с вече познатия режим за автоматично оразмеряване на файла за странициране на виртуалната памет е да гарантира такъв минимален размер, че винаги да може да се запише извадка от паметта. Това се налага тъй като, когато се създава една извадка от паметта тя временно се съхранява именно в Pagefile-а и чак после се прехвърля на твърдия диск, затова за да може да се създаде коректно трябва достатъчно голям минимален размер на файла за странициране. За Windows 8 потребители, които ползват System Mangaed режим на управление на големината на Pagefile-а, то тази опция е най-препоръчителна.
Windows 8 включва и обновен "дизайн" на самия BSOD, който е значително по user friendly, но логиката е същата, затова няма да изпадам в подробности.

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

http://pics.softvisia.com/design/pics/11650/08.png

Първият ред под етикета Technical information (1) показва стоп кода и четирите допълнителни параметъра, подадени към KeBugCheckEx функцията. Когато параметър съдържа адрес на част от операционната система или драйвер, операционната система показва и името на файла (2). Стоп-кодът бива автоматично „декодиран” в текст и това се явява конкретната грешка, която се визуализира в горната част (3). В случая това е стоп код 0x000000D1 (1) което е еквивалентно на грешката DRIVER_IRQL_NOT_LESS_OR_EQUAL (3), причинена от драйвера myfault.sys (2). Toзи вариант на син екран е идеалният, защото ни показва цялата нужна информация за отстраняване на проблема. Най-вече трябва да се обърне внимание на драйверът, причинил срива. В случая съвсем ясно се вижда, че виновникът е 3rd party драйверът myfault.sys. Оттук нататък (след като драйверът е известен) логичните стъпки биха били да се обнови въпросният драйвер, който причинява проблема с по-нова версия или да се обърне внимание на изправността на устройството, асоциирано със съответния драйвер.
Тук трябва да се направи една голяма забележка, че ако видите драйвер, част от Windows като например ntfs.sys, tcpip.sys то почти сигурно не е той виновникът, а става въпрос най-вероятно за хардуерен проблем.

http://pics.softvisia.com/design/pics/11650/09.png

Този син екран се различава значително от предходния. Най-важното е, че липсва информация за драйвера, причинил синия екран. Стоп кодът тук не е особено полезен. Най-важният момент при такива сини екрани е частта, която казва да се пусне Driver Verifier срещу непознати или подозрителни драйвери. Driver Verifier е инструмент, вграден в Windows, който позволява изпълнение на редица тестове, които проверяват до колко е стабилен даден драйвер при различни условия. В случая той е безценен помощник тъй като налага мониторинг над дадения драйвер и при изпълнение на невалидна операция веднага го „хваща” и това се отразява върху синия екран моментално. Ръководство за работа с Driver Verifier можете да намерите тук. В случая съветът от синия екран за активиране на Driver Verifier срещу на скоро инсталирани драйвери или такива в чийто стабилност се съмнявате е най-добър, но имайте предвид, че трябва да го правите един по един. Например ако на скоро сте инсталирали нова антивирусна (или някакво хардуерно устройство) и получавате сини екрани, активирайте DV само за драйверите на въпросната антивирусна като е препоръчително всеки да тествате отделно.

http://pics.softvisia.com/design/pics/11650/10.png

След като активирате Driver Verifier познатият син екран придобива съвсем различен вид. Вече можете да видите кой е виновникът и дори точният проблем.

http://pics.softvisia.com/design/pics/11650/11.png

Този син екран е пример за случай, когато не се визуализира нито информация за драйвер, нито някаква подсказка как да се справим с проблема, освен типичните неща, които присъстват на всеки син екран. Точно до тук са и възможностите на този метод за справяне със сините екрани затова минаваме към варианта за анализ с помощта на WinDbg. По принцип работата с WinDbg в това число и анализирането на файлове с извадка от паметта може да се каже, че е почти цяла наука и изисква много добри познания за архитектурата и вътрешните механизми на дадената операционна система, но простият анализ е нещо съвсем елементарно, което всеки може да направи. Под „простия анализ” имам в предвид евристичният метод, чрез който WinDbg се опитва да покаже кой е виновникът при отваряне на файл с извадка от паметта. Другата фаза на „простия анализ” е изпълнението на командата !analyze –v, която дава по-подробна информация за проблема, но нейното изпълнение не е задължително тъй като както казах, WinDbg се опитва автоматично да покаже проблемния драйвер. В следващите редове ще ви дам инструкции как да подготвите системата за анализ на файлове с извадка и как да отворите такъв файл в WinDbg, извършвайки най-базовия и елементарен възможен анализ. За пример ще взема файла с извадка от паметта, генериран при синия екран по-горе, който към момента не ни дава никаква информация кой е възможният виновник.

Първото нещо, което трябва да се направи е да се уверите, че системата ви е конфигурирана да създава т.нар. Kernel Memory Dump като това е валидно само за потребители на Windows XP. Windows Vista и 7 по подразбиране създават Kernel Memory Dump и ако не сте променили изрично настройката то можете да прескочите тази стъпка.

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

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

Забележка: За за да се генерира файл с извадка от паметта на устройство C:\, трябва да има достатъчно свободно място и файл за странициране на виртуалната памет (Pagefile) с подходящ размер. Обикновено Кernel Memory dump файловете са около 100-500 MB.

Конфигурирането системата да създава Kernel Memory Dump става така (за Windows XP):

http://pics.softvisia.com/design/pics/11650/12.PNG

След като конфигурирате системата да създава Kernel Мemory dump, трябва да инсталирате WinDbg, който е част от пакета Debugging Tools for Windows

След като го инсталирате и стартирате WinDbg първото нещо, което трябва да се направи е да се конфигурират символните таблици, така че да се ползва Microsoft Symbol Server. По този начин WinDbg ще сваля символните таблици автоматично при поискване като ще пази и тяхно локално копие на диска. За целта е необходимо да се направи следното:

1) Отваряте менюто File и избирате команда Symbol File Path…

http://pics.softvisia.com/design/pics/11650/13.png

2) В появилия се прозорец в полето Symbol path въвеждате srv*c:\symbols*http://msdl.microsoft.com/download/symbols. Като можете да промените C:\symbols на нещо друго по ваше желание, ако например искате да пазите локалното копие на символните таблици на друго място на диска. След като сте готови потвърждавате с ОК.

http://pics.softvisia.com/design/pics/11650/14.png

Отварянето на файл с извадка от паметта става чрез избиране на менюто File отново и команда Open Crash dump. След това навигирате до X:\Windows и избирате файла Memory.dmp.

http://pics.softvisia.com/design/pics/11650/15.png

Веднага след отваряне на файла, WinDbg извършва автоматичен анализ на файла с извадка и извежда информация кой е причинителят. В случая евристичният метод на WinDbg коректно е разпознал причинителя на синия екран, за който стана дума по-рано и това е драйверът myfault.sys. Тук е моментът да кажа, че е в сила правилото, което споменах по-рано, че ако видите име на вътрешен драйвер като например ntfs.sys то вероятно става въпрос за грешка при анализа и това не е реалният причинител на срива, а е по-вероятно да е хардуерен проблем или нещо друго. В такъв случай се налага ръчно детайлно анализиране, но това е извън обхвата на тази тема и няма да го разглеждаме.

http://pics.softvisia.com/design/pics/11650/16.png

Ако искате да получите повече информация за срива, освен кой е причинителят, можете да изпълните команда !analyze –v, показваща информацията, която виждате на скрийншота по-долу. Най-интересната част от информацията е секцията SТАCK_TEXT, в която виждате хронологично какво се е случило в момента на срива като се разглежда отдолу нагоре. Последните редове (най-горните) показват, че е e зареден 3rd party компонент myfault.sys и веднага след него е извикана функцията KeBugCheckEx, за която споменах в началото на статията, че всъщност тя визуализира синия екран. Логично компонентът, който се намира под нея е виновникът за срива тъй като той е съдържал последния код преди извикването на функцията KeBugCheckEx. Отделно останалите компоненти съдържат идентификатор nt, което означава че са системни и е много малко вероятно те да са причината за срива. Именно подобна логика следва и евристичният модел за автоматичен анализ на WinDbg, който ни показа в началото, че Myfault е виновникът. Както казах обаче имайте едно на ум, че не винаги това е вярно, особено ако сочи към вътрешен компонент.

http://pics.softvisia.com/design/pics/11650/17.png

И в контекста на последното изречение по-горе стигаме до момента как да разберем, ако има хардуерен проблем.

За да се отговори на този въпрос е необходимо да се проведат тестове на основния хардуер на компютъра като оперативната памет, твърдият диск, процесор /чипсет и графичния контролер. Също така по време на тестовете трябва да се наблюдават работните температури и напреженията на компонентите. Ако на скоро например сте правили промени по хардуерната конфигурация (да си представим добавили сте още RAM) е добре да се тества без новия компонент дали има проблеми. Идеята е да се изолира потенциално проблемния компонент и да се прибегне до решаване на проблема по един или друг начин.

За тестване на хардуер се използват специализирани инструменти. В следващите редове ще дам връзки към по-популярните от тях:

Тестване на твърди дискове

Western Digital (WD) - Data Lifeguard Diagnostic for Windows
Seagate - SeaTools for Windows
Hitachi - Drive Fitness Test
Samsung - ES-Tool
ExcelStor - ESTEST

Ако твърдият ви диск е по-екзотичен, като например Toshiba, то можете да използвате диагностичния инструмент на Hitachi (DFT), който работи на повечето популярни дискове.

Забележка: Стартирайте първо късия тест. Ако инструментът, с който тествате, даде грешка още на късия тест то е почти сигурно, че дискът е проблемен и общо взето няма смисъл да губите време с дългия тест (дългият тест отнема много време). Ако обаче късият не открие грешка, задължително стартирайте и дългия, за да потвърдите или отхвърлите резултата от късия.

Тестване на паметта

За началото можете да пуснете Super PI Mod v1.5 с конфигурация за изчисление 32M (Calculate --> 32M --> OK). Ако даде грешка по време на изпълнението е почти сигурно, че има проблем със стабилността на паметта и няма смисъл от обстойни тестове. Ако обаче мине ОК, тогава тествайте поне 1-2 часа с някой от следните инструменти:

Тестване на видеокартата

Tест на процесор, чипсет, памет

Забележка: Оrthos и Prime95 почти се припокриват тъй че е въпрос на личен избор кое от двете ще изберете.

Забележка: Ако искате да тествате процесор, памет, чипсет с помощта на Orthos/Prime95, изберете тестът Blend. Не е необходимо да променяте приоритета на нишките (падащото списъчно поле Priority) на Orthos , но ако целите да вдигнете максимална температура, можете да го качите, като по този начин ще се намали броя на контекстните превключвания и това ще доведе, евентуално, до малко по-висока температура на процесора (ако искате да тествате охлаждането, например).

Забележка: За съвременните процесори (особено тези с поддръжка на AVX/AVX2) е подходящо да се ползва LinX, като е добре да се върти поне 1 час, с максимално заделена памет, без машината да страницира. Така се постига максимално натоварване и съответно загряване.

Докато тествате процесор, видеокарта, твърд диск е добре да следите и техните работни температури, както и изходните напрежения на захранващия блок (+3,3V, +5V и 12V линиите). За целта можете да използвате следните пособия:

Забележка: Бих искал да обърна внимание относно "измерването" на напрежение софтуерно. На практика това е фалшив метод, истинският е хардуерен, с помощта на мултиметър. Ако всички отчетени стойности са в границата на +/-10% от указаното напрежение се считат за приемливи, въпреки че обикновено се взима по-строг допуск от 5%.

За ATX захранващите блокове спецификациите изискват напреженията да бъдат с отклонение максимум 5%, с изключение на захранването от 3,3v, което трябва да е в границата +/-4%. Ако трябва да дам конкретни цифри това ще са:

- за 3,3V - минимум 3,135 и максимум 3,465
- за 5V - минимум 4,75 и максимум 5,25
- за 12V - минимум 11,4 и максимум 12,6

Ако разполагате с цифров мултиметър мога да ви кажа с няколко думи как става измерването на напреженията.

Превключвателят се поставя в положение DCV на обхват 20(V).

Пример:

http://pics.softvisia.com/design/pics/11650/18.JPG

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

След това имаме два възможни начина за измерване на изходните напрежения на захранващия блок. Първият от тях е през 4-пиновия молекс конектор, който се използва за захранване на оптични устройства, твърди дискове, вентилатори и др. За да измерите +5V линията през молекс конектора е необходимо да вкарате червената сонда на мултиметъра в извода, свързан с червен кабел (извод номер 4) на молекс конектора, а черната сонда в един от двата извода, свързани с черни кабели (изводи номер 2 или 3), които представляват земя (GND). Процедурата за измерване на +12V линията е същата само трябва да преместите червената сонда на извод номер 1 на молекс конектора, който е свързан с жълт кабел. Добре е да проведете тестовете, когато машината е под товар. За целта можете да използвате инструментите Orthos, Prime95 и OCCT.

Вторият начин за измерване, който позволява и измерване на +3,3V линията сe нарича задно измерване като за целта се ползва главният ATX конектор, свързан с дъното. Идеята е да бръкнете с червената сонда в съответния отвор (напрежение, което искате да мерите), така че сондата да осъществи контакт със задния край на металната клема. Тук отново с червен цвят на кабела е +5V, а с жълт +12V. Toва, което може би ще искате да измерите чрез този метод, е +3,3V линията, тъй като тя не може да се измери чрез предходния метод (с използване на молекс конектора). За да измерите +3,3V трябва да пъхнете червената сонда при отворите с оранжев кабел, а черният да отиде на маса, което може да бъде и самото шаси (кутията). Като цяло този метод е доста по-неудобен, но пък позволява да се измери +3,3V линията. Друг е въпросът, че в днешно време най-натоварена е +12V линията и на нея трябва да се обърне подобаващо внимание.

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

Другите възможни причини са още по-дребни, като например калпав SATA порт или интерфейсен кабел, като цяло лош контакт при конекторите/слотовете и др. Потенциалните причини за син екран от хардуерна гледна точка наистина са доста и в краен случай ако не можете да се справите сами най-добре дайте машината за диагностика от фирма или човек, който е наясно с нещата.

Последният вариант за син екран както казах в началото е възможността за грешка в кода на Microsoft. За целта е добре да се уверите, че операционната ви система е максимално обновена. Tова може да стане посредством Windows Update. За Windows XP можете да разгледате тази статия.

При Windows 7 обновяването е още по-лесно:

1. Отваряте Start Menu-то и избирате All Programs.

http://pics.softvisia.com/design/pics/11650/19.png

2. Кликвате върху иконката Windows Update.

http://pics.softvisia.com/design/pics/11650/20.png

3. След като се отвори Windows Update кликвате на бутона Check for updates и ако има намерени актуализации ги инсталирате (системата може да поиска рестарт).

http://pics.softvisia.com/design/pics/11650/21.png

Ако и това не реши проблема вероятно става въпрос за някаква по-специфична грешка и ще се наложи по-детайлно претърсване на сайта на Microsoft за евентуална поправка (fix) ако към момента е налична такава.

В заключение бих искал да кажа, че се надявам хората да си променят представите за синия екран и да престанат да го асоциират с „бъгавия Windows”. Да, наистина когато се появи син екран, именно Windows изглежда зле, но това е предпазна мярка за опазване цялостта на потребителските данни. Нещо, което никога не е трябвало да се случва се случва в момента и затова операционната система спира изпълнение. Де факто потребителят трябва да благодари за тази предпазна мярка, тъй като, както казах тя гарантира цялостта на данните му, което е едно от най-важните неща.

И наистина последно: винаги когато става въпрос за BSOD, можете да компресирате Memory.dmp файла (намиращ се в X:\Windows) и да го прикачите към коментара си тук във форума, за да може аз или друг потребител да съдействат, ако има възможност.

III. Тайната "функция" на сините екрани

Брех, че скучна статия... ако сте се прекарали да четете цялата ненужна информация по-горе, сигурно вече сте заспали или сте затворили страницата/таба още след точка I, но ето нещо съществено важно (за тия които са стигнали до тук). Ако не сте прочели/разбрали нищо от информацията по-горе (точки I и II) не е проблем, но следващите редове/инструкции са най-съществените. Голяма част от хората, особено неопитните потребители, се шашкат при появата на лошия син екран, който с лека ръка им затрива целия труд до момента, тъй като се налага рестарт от копчето (ако някой добър човек/админ им е конфигурирал системата да не се рестартира автоматично при син екран) т.е. загуба на работата по всички отворени файлове, а те горките нямат още навика да си съхраняват периодично работата. Та, в тоя ред на мисли, появата на син екран и още повече реакцията на потребителя, може да се окаже забавно изживяване, още повече, ако го причините вие и то в подходящ момент. Хубава идея (безспорно), ама как да стане това в рамките на шегата, без реална загуба на данни (фалшив BSOD)? Отговорът се крие в негово величество Sysinternals BlueScreen. Това е скрийнсейвър-убиец, който имитира сини екрани с огромна степен на реалистичност. И като казвам реалистичност, скрийнсейвърът е толкова добър, че дори събира данни за машината, на която е стартиран, и всъщност сините екрани, които показва, включват реални имена на драйвери, които се съдържат на въпросната машина. Найс, а?

Инсталацията е елементарна. Просто сваляте архива от линка по-горе, разархивирате го и поставяте файла SysInternalsBluescreen.scr в Х:\Windows\System32. След това отивате в настройките на скрийнсейвъра и го селектирате. Може да се уверите в реалистичността му чрез бутона Preview преди да го сетнете.

Не си мислете, че има защитени - работи на всичко от XP до 7 (тествано). Единствено симулацията на буут процеса не изглежда особено добре под 7, но голяма работа. Рядко се стига до там, първите секунди след появата на синия екран (както и реакциите на потребителя, включващи често споменаване на близки роднини на хората от Microsoft), са най-важните и интересните.

Еми, това е то, истинският финал. Надявам се цялата статия или поне последната част да са полезни и интересни за вас.

Aвтор: Лазар Л. Канелов (l.kanelov)

Всички авторски права върху съдържанието на статията и снимковият материал са запазени. Забранено е разпространяването и/или модифицирането на статията или части от нея без изричното съгласие на автора.

dimd · Август 2, 2010

Чудесна статия !

melmak · Август 2, 2010

Браво! Отлична статия.

Maniac · Август 10, 2010

Много добре обяснено! Браво!

Nightmare · Август 10, 2010

Определено, една от най-добрите статии в форума

qbasix · Юни 2, 2011

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

naydenantonov80 · Юни 5, 2011

Много, много полезна статия. Браво.

BBoyCataclysm · Октомври 9, 2011

Не мога да разбера защо като напиша srv*c:\symbols*http://msdl.microsoft.com/download/symbols после не мога да намеря файла Memory.dmp

Моля помогнете,защото имам същия проблем с BSOD и не мога да го оправя.

BBoyCataclysm · Октомври 9, 2011

Ако ще помогне,като ми се включи синия екран ми излиза stop:0x000000F4(0x00000003,0xFB0B8DA0,0xFB0B8F14,0x805FB02E)

някакви идеи ?

BBoyCataclysm · Октомври 9, 2011

по някакъв начин успях да пусна файла и вижте какво ми излезе

Microsoft ® Windows Debugger Version 6.12.0002.633 X86

Loading Dump File [C:\WINDOWS\MEMORY.DMP]

Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Page e87fd too large to be in the dump file.

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

THIS DUMP FILE IS PARTIALLY CORRUPT.

KdDebuggerDataBlock is not present or unreadable.

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

Page e87fd too large to be in the dump file.

Unable to read PsLoadedModuleList

Page e87fd too large to be in the dump file.

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

THIS DUMP FILE IS PARTIALLY CORRUPT.

KdDebuggerDataBlock is not present or unreadable.

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

KdDebuggerData.KernBase < SystemRangeStart

Windows XP Kernel Version 2600 UP Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Machine Name:

Kernel base = 0x00000000 PsLoadedModuleList = 0x8055b1c0

Debug session time: Sun Oct 9 15:03:07.156 2011 (UTC + 3:00)

System Uptime: 0 days 0:04:52.719

Page e87fd too large to be in the dump file.

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

THIS DUMP FILE IS PARTIALLY CORRUPT.

KdDebuggerDataBlock is not present or unreadable.

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

Page e87fd too large to be in the dump file.

Unable to read PsLoadedModuleList

Page e87fd too large to be in the dump file.

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

THIS DUMP FILE IS PARTIALLY CORRUPT.

KdDebuggerDataBlock is not present or unreadable.

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

KdDebuggerData.KernBase < SystemRangeStart

Loading Kernel Symbols

Page e87fd too large to be in the dump file.

Unable to read PsLoadedModuleList

GetContextState failed, 0xD0000147

CS descriptor lookup failed

GetContextState failed, 0xD0000147

Page e87fd too large to be in the dump file.

GetContextState failed, 0xD0000147

Unable to get program counter

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

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

* *

* Bugcheck Analysis *

* *

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

Use !analyze -v to get detailed debugging information.

BugCheck F4, {3, fb0e45c0, fb0e4734, 805fb02e}

***** Debugger could not find nt in module list, module list might be corrupt, error 0x80070057.

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

| |

| NT symbols are not available |

| |

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

GetContextState failed, 0xD0000147

Unable to read selector for PCR for processor 0

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to read selector for PCR for processor 0

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to get current machine context, NTSTATUS 0xC0000147

GetContextState failed, 0xD0000147

Unable to read selector for PCR for processor 0

GetContextState failed, 0xD0000147

Unable to read selector for PCR for processor 0

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Followup: MachineOwner

---------

GetContextState failed, 0xD0000147

Моля помогнете

Night_Raven · Октомври 9, 2011

Не мисля, че може да се помогне. Дъмп файлът е повреден. Ще трябва да друг. Явно си повредил, като си рестартирал, преди да е бил създаден напълно.

BBoyCataclysm · Октомври 9, 2011

Добре де ами как да го поправя ?

Извинявам се много понеже съм тъпичък,видях къде ми е грешката и направих нов дъмп фаил.В смисъл показа ми това което трябваше ,но не знам как да го оправя

Microsoft ® Windows Debugger Version 6.12.0002.633 X86

Loading Dump File [C:\WINDOWS\MEMORY.DMP]

Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 2600.xpsp.080413-2111

Machine Name:

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0

Debug session time: Sun Oct 9 20:23:09.265 2011 (UTC + 3:00)

System Uptime: 0 days 1:50:59.837

Loading Kernel Symbols

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

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

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

Loading User Symbols

PEB is paged out (Peb.Ldr = 7ffdc00c). Type ".hh dbgerr001" for details

Loading unloaded module list

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

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

* *

* Bugcheck Analysis *

* *

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

Use !analyze -v to get detailed debugging information.

BugCheck F4, {3, f8d3b5b0, f8d3b724, 805fb02e}

unable to get nt!KiCurrentEtwBufferOffset

unable to get nt!KiCurrentEtwBufferBase

Probably caused by : FlashPlayer.exe

Followup: MachineOwner

Night_Raven · Октомври 10, 2011

Архивирай MEMORY.DMP файла, качи го на Megaupload и дай линк.

BBoyCataclysm · Октомври 10, 2011

http://www.megaupload.com/?d=RVD88UNG етооо

Night_Raven · Октомври 11, 2011

Според дъмп файла най-вероятно Flash Player е причината. Не че не е възможно, но е малко вероятно според мен. Все пак се увери, че плеърът е актуална версия. Освен това провери и дали драйверите са актуални.

Статия: Сините екрани (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

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

Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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