I Kакво представлява синият екран и какви са причните да се появи?
(ъъъм...син екран с бели букви? Не баш...)
Всички почти са виждали поне въднъж син екран, но едва ли са много хората, които са нaясно какво точно представлява и какво кара системата да го покаже. С няколко думи ще се опитам да дам отговор на този въпрос.
Синият екран се визуализира в резултат на изпълнението на системната функция 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 XP
1) Отворете System Properties чрез десен клик върху My Computer и избиране на Properties от контекстното меню.
2) След като се отвори прозорецът System Properties изберете таба Advanced.
3) В секцията Startup and Recovery кликнете върху бутона Settings.
4) В появилия се прозорец Startup and Recovery е необходимо да премахнете отметката пред етикета Automatically restart в секцията System failure и да потвърдите настройките чрез кликване на бутона ОК.
Windows 7
1) Отворете System Properties чрез десен клик върху Computer и избиране на Properties от контекстното меню.
2) В прозореца System кликнете върху бутона Advanced system settings.
3) В секцията Startup and Recovery кликнете на бутона Settings.
4) В секцията System failure махнете отметката пред етикета Automatically restart и потвърдете чрез натискане на бутона ОК.
Windows 8
1) Отворете System Properties от Control Panel->System and Security->System или натиснете Win + X и от менюто изберете System.
2) В прозореца System кликнете върху бутона Advanced system settings.
3) В секцията Startup and Recovery кликнете на бутона Settings.
4) В секцията System failure махнете отметката пред етикета Automatically restart, ако по някаква причина не е избран Automatic memory dump то от падащото списъчно поле го селектирайте него (или Kernel memory dump, двете са еквивалентни, виж бележката по-долу!), след това потвърдете чрез натискане на бутона ОК.
При 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, който е значително по "юзър френдли", но логиката е същата, затова няма да изпадам в подробности.
Сега вече системата няма да се рестартира при поява на син екран и спокойно можем да разгледаме съдържанието му.
Първият ред под етикета Technical information (1) показва стоп кода и четирите допълнителни параметъра подадени към KeBugCheckEx функцията. Когато параметър съдържа адрес на част от операционната система или драйвер, операционната система показва и името на файла (2). Стоп-кодът бива автоматично „декодиран” в текст и това се явява конкретната грешка, която се визуализира в горната част (3). В случая това е стоп код 0x000000D1 (1) което е еквивалентно на грешката DRIVER_IRQL_NOT_LESS_OR_EQUAL (3), причинена от драйвера myfault.sys (2). Toзи вариант на син екран е идеалният, защото ни показва цялата нужна информация за остраняване на проблема. Най-вече трябва да се обърне внимание на драйверът, причинил срива. В случая съвсем ясно се вижда, че виновникът е 3rd party драйверът myfault.sys. Oт тук нататък (след като драйверът е известен) логичните стъпки биха били да се обнови въпросният драйвер, който причинява проблема с по-нова версия или да се обърне внимание на изправността на устройството, асоциирано със съответния драйер.
Тук трябва да се направи една голяма забележка, че ако видите драйвер, част от Windows като например ntfs.sys, tcpip.sys то почти сигурно не е той виновникът, а става въпрос най-вероятно за хардуерен проблем.
Този син екран се различава значително от предходния. Най-важното е, че липсва информация за драйвера, причнил синия екран. Стоп кодът тук не е особено полезен. Най-важният момент при такива сни екрани е частта, която казва да се пусне Driver Verifier срещу непознати или подозрителни драйвери. Driver Verifier е инструмент, вграден в Windows, който позволява изпълнение на редица тестове, които проверяват до колко е стабилен даден драйвер при различни условия. В случая той е безценен помощник тъй като налага мониторинг над дадения драйвер и при изпълнение на невалидна операция веднага го „хваща” и това се отразява върху синия екран моментално. Ръководство за работа с Driver Verifier можете да намерите тук. В случая съветът от синия екран за актвиране на Driver Verifier срещу на скоро инсталирани драйвери или такива в чийто стабилност се съмнявате е най-добър, но имайте предвид, че трябва да го правите един по един. Например ако на скоро сте инсталирали нова антивирусна (или някакво хардуерно устройство) и получавате сини екрани, активирайте DV само за драйверите на въпросната антивирусна като е препоръчително всеки да тествате отделно.
След като активирате Driver Verifier познатият син екран придобива съвсем различен вид. Вече можете да видите кой е виновникът и дори точният проблем.
Този син екран е пример за случай, когато не се визуализира нито информация за драйвер, нито някаква подсказка как да се справим с проблема, освен типичните неща, които присъстват на всеки син екран. Точно до тук са и възможностите на този метод за справяне със сините екрани затова минаваме към варианта за анализ с помощта на 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 става така (касae Windows XP):
След като конфигурирате системата да създава Kernel Мemory dump трябва да инсталирате WinDbg, който е част от пакета Debugging Tools for Windows
След като го инсталирате и стартирате WinDbg първото нещо, което трябва да се направи е да се конфигурират символните таблици, така че да се ползва Microsoft Symbol Server. По този начин WinDbg ще сваля символните таблици автоматично при поискване като ще пази и тяхно локално копие на диска. За целта е необходимо да се направи следното:
1) Отваряте менюто File и избирате команда Symbol File Path…
2) В появилия се прозорец в полето Symbol path въвеждате srv*c:\symbols*http://msdl.microsoft.com/download/symbols. Като можете да промените C:\symbols на нещо друго по ваше желание, ако например искате да пазите локалното копие на символните таблици на друго място на диска. След като сте готови потвърждавате с ОК.
Отварянето на файл с извадка от паметта става чрез избиране на менюто File отново и команда Open Crash dump. След това навигирате до X:\Windows и избирате файла Memory.dmp.
Веднага след отваряне на файла WinDbg извършва автоматичен анализ на файла с извадка и извежда информация кой е причинителят. В случая евристичният метод на WinDbg коректно е разпознал причинителя на синия екран, за който стана дума по-рано и това е драйверът myfault.sys. Тук е моментът да кажа, че е в сила правилото, което споменах по-рано, че ако видите име на вътрешен драйвер като например ntfs.sys то вероятно става въпрос за грешка при анализа и това не е реалният причинител на срива, а е по-вероятно да е хардуерен проблем или нещо друго. В такъв случай се налага ръчно детайлно анализиране, но това е извън обхвата на тази тема и няма да го разглеждаме.
Ако искате да получите повече информация за срива, освен кой е причинителят можете да изпълните команда !analyze –v, показваща информацията, която виждате на скрийншота по-долу. Най-интересната част от информацията е секцията SТАCK_TEXT, в която виждате хронолигично какво се е случило в момента на срива като се разглежда отдолу нагоре. Последните редове (най-горните) показват, че е e зареден 3rd party компонент myfault.sys и веднага след него е извикана функцията KeBugCheckEx, за която споменах в началото на статията, че всъщност тя визуализира синия екран. Логично компонентът, който се намира под нея е виновникът за срива тъй като той е съдържал последния код преди извикването на функцията KeBugCheckEx. Отделно останалите компоненти съдържат идентификатор nt, което означава че са системни и е много малко вероятно те да са причината за срива. Именно подобна логика следва и евристичният модел за автоматичен анализ на WinDbg, който ни показа в началото, че Myfault е виновникът. Както казах обаче имайте едно на ум, че не винаги това е вярно, особено ако сочи към вътрешен компонент.
И в контекста на последното изречение по-горе стигаме до момента как да разберем, ако има хардуерен проблем.
За да се отговори на този въпрос е необходимо да се проведат тестове на основния хардуер на компютъра като оперативната памет, твърдият диск, процесор /чипсет и графичния контролер. Също така по време на тестовете трябва да се наблюдават работните температури и напреженията на компонентите. Ако на скоро например сте правили промени по хардуерната конфигурация (да си представим добавили сте още RAM) е добре да се тества без новия компонент дали има проблеми. Идеята е да се изолира потенциално проблемния компонент и да се прибегне до решаване на проблема по един или друг начин.
За тестване на хардуер се използват специализирани инструменти. В следващите редове ще дам връзки към по-популярните от тях:
Тестване на твърди дискове
- Western Digital (WD) - Data Lifeguard Diagnostic for Windows
- Seagate - SeaTools for Windows
- Hitachi - Drive Fitness Test
- Samsung - ES-Tool
- ExcelStor - ESTEST
Забележка: Стартирайте първо късия тест. Ако инструментът, с който тествате даде грешка още на късия тест то е почти сигурно, че дискът е проблемен и общо взето няма смисъл да губите време с дългия тест (дългият тест отнема много време). Ако обаче късият не открие грешка, задължително стартирайте и дългия, за да потвърдите или отхвърлите резултата от късия.
Тестване на паметта
За началото можете да пуснете Super PI Mod v1.5 с конфигурация за изчисление 32M (Calculate --> 32M --> OK). Ако даде грешка по време на изпълнението е почти сигурно, че има проблем със стабилността на паметта и няма смисъл от обстойни тестове. Ако обаче мине ОК, тогава тествайте поне 1-2 часа с някой от следните инструменти:Тестване на видеокартата
Tест на процесор, чипсет, памет
Забележка: Оrthos и Prime95 почти се припокриват тъй че е въпрос на личен избор кое от двете ще изберете. Аз лично ползвам по-често Orthos.
Забележка: Ако искате да тествате процесор, памет, чипсет с помощта на Orthos/Prime95 изберете теста Blend. Не е необходимо да променяте приоритета на нишките (падащото списъчно поле Priority) на Orthos , но ако целите да вдигнете максимална температура можете да го качите като по този начин ще се намали броят на контекстните превключвания и това ще доведе евентуално до малко по-висока температура на процесора (ако искате да тествате охлаждането например).
Забележка: За съвременните процесори (особено тези с AVX) е подходящо да се ползва 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).
Забележка: Съществуват мултимери с автоматична настройка на обхвата т.е. уредът автоматично разпознава в какъв обхват се намира измерваната стойност и я показва коректно, но повечето и по-евтините изискват ръчна настройка. Пример за такъв мултимер е този, показан на снимката по-горе.
След това имаме два възможни начина за измерване на изходните напрежения на захранващия блок. Първият от тях е през 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.
2. Кликвате върху иконката Windows Update.
3. След като се отвори Windows Update кликвате на бутона Check for updates и ако има намерени актуализации ги инсталирате (системата може да поиска рестарт).
Ако и това не реши проблема вероятно става въпрос за някаква по-специфична грешка и ще се наложи по-детайлно претърсване на сайта на 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)
Всички авторски права върху съдържанието на статията и снимковия материал са запазени. Забранено е разпространяването и/или модифицирането на статията или части от нея без изричното съгласие на автора.