Jump to content

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


Aquarius

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

  • Отговори 159
  • Създадена
  • Последен отговор

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

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

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

Ще е добре като за начало да се увериш, че всички допълнителни драйвери (за видео карта, звукова карта, мрежова карта и т.н.) са актуални.

 

Поздравления Night_Raven,сканирах и наистина се оказа че един от драйверите ми не е актуален : http://i.imgur.com/KXLa1.png

 

Благодаря Night_Raven :gentlemen:

 

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

Имам нещо предвид. ;)

 

Разбира се B-boy/Style/,следващия път ще запазя дъмп файла и ще го прикача! :)

Благодаря и на теб B-boy/Style/! :gentlemen:

Link to comment
Сподели другаде

Лично аз не бих се доверил на подобни програми за драйвери.

 

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

NIght_Raven,понеже зная че си прав на 100% ,ще я изтрия програмката,тенкс за препоръката! :gentlemen:

Link to comment
Сподели другаде

  • 3 weeks later...
  • 4 months later...

Ще пусна тук един лог от BSOD-s, при който посочената методика изглежда не върши работа. bug.zip

 

Нещо не можах да разбера какъв е смисълът на въпросния коментар, защото това не е пълноценен .dmp файл, който да може да се анализира и да се обсъдят по-сложни техники за "ръчен" анализ и комбинация с други инструменти като Driver Verifier. Факт е, че понякога автоматичният анализ на база евристични методи, който WinDbg реализира не е особено точен и се налага именно на ръка да се разчовърка извадката от паметта с цел да се разбере какво се случва.

 

Относно прикачения файл - първо бих искал да кажа, че да се създават Minidump извадки е почти безмислено за сериозен анализ, защото количеството полезна информация е крайно недостатъчно. За целта е добре операционните системи да се конфигурират да използват Kernel Memory Dump, защото той предлага най-добро съотношение обем/полезна информация.

 

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

Link to comment
Сподели другаде

Нещо не можах да разбера какъв е смисълът на въпросния коментар....

....

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

Главната идея на предният коментар е, че понякога обикновените методи за анализ не вършат достатъчно добра работа. Тези грешки са натрупани на компютър, който ми беше донесен, за да видя какво се случва. Няма как да върна времето назад, за да направя пълни дъмпове на историята. По-късно може да прикача и дъмповете в компресиран формат, а евентуално и бъдещи от тестове. Програмата не е WinDbg, а Nirsoft BSOD View, която е много сходна.

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

Link to comment
Сподели другаде

Аз лично винаги съм се радвам на troubleshoоting-a на BSOD грешките.

Преди са ми минавали някои интересни програми, които в момента не си спомням (те са десекти), но наскоро почнах да си събирам по-качествените от тях.

Някои от тях са следните:

 

1. Програма главно за диагностика на мрежови проблеми, също така показва драйвърите, Event Viewer логовете и т.н.

 

http://www.bleepingcomputer.com/download/minitoolbox/

 

2. Програма, която предоставя голяма част от необходимата информация за анализ на грешки в изправността на софтуера или хардуера.

 

http://www.majorgeeks.com/SF_Diagnostic_Tool_d6520.html

 

3. Мисля, че тази е ясна - подобна на WindBg за анализ на *.dmp файлове.

 

http://www.majorgeeks.com/BlueScreenView_d6200.html

 

4. Тази доста я хвалят, но досега не ми е оставало време да я тествам...за автоматичен анализ на dump файлове.

 

http://majorgeeks.com/WhoCrashed_Free_Home_Edition_d7442.html

 

5. Това е приложение, което дава информация за кода на грешката. Би трябвало да спести едно ходене до Auhma

 

http://majorgeeks.com/Windows_Error_Lookup_Tool_WELT_d6545.html

 

 

Иначе ето и някои от основните причини за сривовете:

 

1. MBR зараза или друг зловреден код. За анализ може да се използва всеки обновен антируткит скенер като TDSSKiller, aswMBR и т.н.

2. Драйвър (на хардуер или зловреден)...За анализ може да се използва и вградения инструмент в Windows - ntbtlog, а за спиране на драйвъра при небуутваща система може да се използва и Recovery Console с командата - disable "driver name". Друга полезна команда тук е - listsvc. Ако Windows-a буутва може да се използва Driver Verifier (след приключване е добре да се изключи с командата verifier /reset, защото товари доста). :)

3. Дефект в захранването (разлики и пикове в тока), повредена РАМ памет (memtest86+,windows memory diagnostic), повреден процесор (hot cpu tester), прегряване на компонентите, лоши сектори по хардиска (инструмент от сайта на разработчика на хардиска, HDD regenerator, MHDD, spinrite, victoria и т.н.), видеокарта (проблем с охлаждането, лош контакт в гнездото, прах, студена спойка, фабричен дефект), дъно...и т.н.

4. Грешки във файловата система (изисква се chkdsk).

5. Повредени гнезна на регистрите - за анализ трябва да се използва PE диск, който има registry editor, търсене и заместване на бекъп копия на sam файловете...добре е да се разполага с копие от Erunt

6. Софтуерни грешки - като некоректно написани shell обвивки за explorer.exe. За анализ могат да се използват Process Explorer, Autoruns, ShellExView, средствата в Windows Vista/7 - Control Panel\System and Security\Action Center\Reliability Monitor

 

А иначе темата на i.kanelov си е перфектна - хем обяснена добре за начинаещи, хем технически грамотно поднесена и за напредналите потребители, които искат да научат още неща.

Link to comment
Сподели другаде

,

....

А иначе темата на i.kanelov си е перфектна - хем обяснена добре за начинаещи, хем технически грамотно поднесена и за напредналите потребители, които искат да научат още неща.

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

Логично проблемът е дъното или нещо около него, просто ми се искаше и bugcheck-овете да помагаха повече.

Темата на i.kanelov е добра, но случаи като този са особени и труднопокриваеми.

Link to comment
Сподели другаде

В този случай, наличието на Kernel Memory Dump би било от полза, както е споменал колегата. Въпреки това, бих казал, че прегледа на Minidump файла е достатъчен за да се заподозре самия хардуер, инсталиран на системата, което все пак е някаква насока. Но като цяло да, има моменти, в които се налага доста сериозен анализ на стабилността и целостта на хардуерните компоненти за да бъде локализиран даденият проблем.
Link to comment
Сподели другаде

Не знам как слагате разни Viewer-и като Nirsoft BSOD View и WinDbg в едно изречение, след като двете нямат абсолютно нищо общо като идеология. Tова е все едно човек да каже, че Notepad и Visual Studio са „подобни програмки". Да, вярно е, че и на двете може да се "пише" нещо, но приликите спират точно тук.

WinDbg е абсолютно пълноценен дебъгер с извънредно много възможности, включително моят любим режим за локален Live kernel debugging (при вдигнат /debug флаг на операционната система), който аз лично ползвам доста често за получаване на информация, която по друг начин на практика не е достъпна (няма наличен API) и промяна на работата на системата в реално време. Това освен за диагностика и някои други цели е много полезно и при борба със заплахи, базирани на rootkit-и, но това е съвсем друга тема.

Относно проблемната машина – крайно вероятно е неприятностите да идват от дъното и аз лично бих тествал с друго дъно при това положение. Повече от очевидно е, че не е софтуерен проблем и трябва да се концентрираш върху железарията и то както правилно си се ориентирал по метода на изключването, докато откриеш проблемния компонент(и). После вече в името на науката може да се разчовърка допълнително с цел да се открие точно каква е била причината, за да може евентуално (ако е възможно) да се вземат мерки да не се повтаря. Поне аз лично обикновено така правя, но понякога е невъзможно от гледна точка необходимо време, което трябва да се отдели и нужната апаратура. Все пак малко хора имат хубав осцилоскоп и други играчки вкъщи.

 

P.S.: Никнеймът ми е l.kanelov, а не i.kanelov или иначе казано първата буквичка е с ASCII код 108. :)

Link to comment
Сподели другаде

Не знам как слагате разни Viewer-и като Nirsoft BSOD View и WinDbg в едно изречение...

Относно проблемната машина – крайно вероятно е неприятностите да идват от дъното...

P.S.: Никнеймът ми е l.kanelov, а не i.kanelov или иначе казано първата буквичка е с ASCII код 108.

Всъщност ти, l.kanelov го спомена WinDbg като коментар към рапорта, който редпоставиш, като рапорта беше от Nirsoft BSOD View, защото тя беше налична към момента. WinDbg е пълноценен дебъгер, но в точно определеният момент бях просто "прочел" дъмповете с BSOD View. Още самото прочитане ме наведе на хардуерният проблем с дънната платка, нещо което не може да се заключи от дъмповете, ако строго изхождаме от това какво се дава като проблемен драйвер. Дъното е 100% проблемно, като примерът беше нещо средно като показателно, че не винаги дъмповете сами по себе си са ползотворни... В скоро време всички кондензатори ще бъдат заменени.

п.п Извинявам се за неточността в изписването на никнейма.

Link to comment
Сподели другаде

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

Гост
Отговори на тази тема

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   Не можете да качите директно снимка. Качете или добавете изображението от линк (URL)

Loading...

×
×
  • Създай ново...