Дъмп на паметта на ядрото на Windows 7, където се намира. Използване на дъмп на паметта за диагностициране на сривове

Оставете коментар 6,950

Здравейте приятели, днес ще разгледаме интересна тема, което ще ви помогне в бъдеще, когато се появи син екран на смъртта (BSoD).

Подобно на мен, много други потребители трябваше да наблюдават появата на екран със син фон, на който пише нещо (бяло на синьо). Това явление показва критичен проблем, както в софтуер, например конфликт на драйвери или физическа неизправност на някой компютърен компонент.

Наскоро отново получих проблем със син екран в Windows 10, но бързо се отървах от него и скоро ще ви разкажа за него.

Искам да ? След това последвайте връзката.

Така че повечето потребители не знаят, че BSoD може да бъде анализиран, за да разберат по-късно проблемите с критичните грешки. За такива случаи Windows създава на диск специални файлове– тогава ще ги анализираме.

Има три вида дъмп на паметта:

Пълен дъмп на паметта– тази функция ви позволява да запазите изцяло съдържанието оперативна памет. Използва се рядко, защото си представете, че имате 32 GB RAM, с пълен дъмп, целият този обем ще се съхранява на диска.

Основен дъмп– запазва информация за режима на ядрото.

Малък дъмп на паметта– запазва малко количество информация за грешки и заредени компоненти, които са присъствали в момента на възникване на неизправността на системата. Ще използваме този тип dump, защото ще ни даде достатъчно информация за BSoD.

Местоположението както на малкия, така и на пълния дъмп е различно, например малкият дъмп се намира в следния път: %systemroot%\minidump.

Пълният дъмп е тук: %systemroot%.

За анализиране на дъмпове на паметта има различни програми, но ще използваме две. Първият е Microsoft Kernel Debuggers, както подсказва името, помощна програма от Microsoft. Можете да го изтеглите от официалния сайт. Втората програма е BlueScreenView, безплатна програма, изтеглете от тук.

Анализиране на дъмп на паметта с помощта на Microsoft Kernel Debuggers

За различни версиисистеми трябва да изтеглите свой собствен тип помощна програма. Например за 64-битов операционна система, имате нужда от 64-битова програма, за 32-битова програма - 32-битова версия.

Това не е всичко, трябва да изтеглите и инсталирате пакета от символи за отстраняване на грешки, необходими за програмата. Нарича се символи за отстраняване на грешки. Всяка версия от този пакетсъщо се изтегля под конкретна ОС, първо разберете каква система имате и след това изтеглете. За да не се налага да търсите тези символи навсякъде, ето връзката за изтегляне. За предпочитане е инсталацията да се извърши по този път: %systemroot%\symbols.

Сега можете да стартирате нашия дебъгер, чийто прозорец ще изглежда така:

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

Програмата ви позволява да извличате символи директно от мрежата, така че дори не е необходимо да ги изтегляте (съжалявам на тези, които вече са ги изтеглили). Те ще бъдат взети от сървър на Microsoft, така че всичко е защитено. И така, трябва да отворите отново „Файл“, след това „Път на символен файл“ и да въведете следната команда:

SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols

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

Това е всичко. Конфигурирахме програмата по правилния начин, сега започваме да анализираме дъмпове на паметта. В програмата натиснете бутона "файл", Тогава „Отваряне на дъмп за срив“и изберете желания файл.

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

В прозореца, който се показва, можете да въведете команди. Ако влезем !анализирайте –v, тогава ще получим повече информация.

Това е всичко с тази програма. За да спрете дебъгера, изберете „Debug“ и елемента „Stop Debugging“.

Анализиране на дъмп на памет с помощта на BlueScreenView

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

Изтеглете програмата от връзката по-горе и инсталирайте. След като стартирате помощната програма, трябва да я конфигурирате. Отидете на параметрите: „Настройки“ - „ Допълнителни опции" Ще се отвори малък прозорец с няколко елемента. В първия параграф трябва да посочите местоположението на дъмповете на паметта. Те обикновено се намират в пътя C:\WINDOWS\Minidump. След това просто щракнете върху бутона „По подразбиране“.

Какво можете да видите в програмата? Имаме елементи от менюто, част от прозореца с имената на дъмп файловете и втората част на прозореца – съдържанието на дъмповете на паметта.

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

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

В интернет можете да намерите всичко за кода на грешката и драйвера, който може да е виновен за BSoD. За да направите това, щракнете върху „Файл“ и след това "Намери в Google кодгрешки + драйвер".

Можете да покажете само драйверите, които са били налични по време на възникване на грешката. За да направите това, щракнете върху „Настройки“ - „Режим на долния прозорец“ - „Само драйвери, намерени в стека за сривове“. Или натиснете клавиша F7.

За да покажете екранната снимка на BSoD, натиснете F8.

За да покажете всички драйвери и файлове, натиснете F6.

Е, това е всичко. Сега знаете как да разберете за проблема със синия екран на смъртта и ако нещо се случи, намерете решение в Интернет или на този сайт. Можете да предложите своите кодове за грешки и аз ще се опитам да напиша за всяка статия, за да реша проблема.

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

Причина критични грешки Windows, които са придружени от сини екрани (BSOD), често са причинени от драйвер - новоинсталиран или повреден. След като определите кой драйвер причинява грешката, можете да започнете да коригирате проблема: актуализирайте драйвера, върнете се към по-нов. ранна версия, преинсталирайте или премахнете приложението, което е инсталирало драйвера и т.н. Името на драйвера не винаги се показва на син екран. Има обаче много прост начин, който ви позволява да идентифицирате проблемния драйвер за няколко минути, като използвате дъмп на паметта.

Стъпка 1 — Активирайте записа на дъмп памет

Първо трябва да се уверите, че записът на дъмп е активиран. За да направите това, отворете свойствата на системата, като натиснете клавишната комбинация Win+Pause, [в Vista кликнете върху връзката Разширени настройки на системата], отидете на раздела Допълнително, и накрая натиснете бутона.

малъкИзхвърлянията на паметта трябва да са достатъчни за нашите цели.

Обърнете внимание на пътя до папката, където ще бъдат записани, ако възникне критична грешка.

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

Стъпка 2 — Анализиране на дъмпове с помощта на помощната програма MinDumper

В тази статия ще намерите история за помощната програма.

Изтеглете и инсталирайте Инструменти за отстраняване на грешки за Windows. Те са включени в уеб инсталатора на Windows SDK, където след стартиране трябва да изберете Инструменти за отстраняване на грешки в секцията Общи помощни програми.
Изтегли сценарий(kdfe.cmd), който е написан от Александър Суховей и е публикуван на ресурса sysadmins.ru(тъй като не можах да намеря връзка на живо там, предлагам моя собствена). Разархивирайте архива във всяка папка.
Забележка. В случай на нестандартно местоположение на папката Програмните файловеможе да се наложи да зададете kdfe.cmd на пътя към папката, където са инсталирани инструментите за отстраняване на грешки за Windows. Използвайте променливата dbgpath на ред 41.

Стъпка 3 - Анализиране на дъмпа на паметта

Сега всичко се свежда до изпълнение на една команда. Отворете командния ред и отидете до папката, в която сте извлекли kdfe.cmd. Стартирайте файла, като посочите пътя до файла с дъмп на паметта като параметър (в примера по-долу файлът се нарича Mini1110307-01.dmp)

Всички Windows системи при откриване фатална грешканаправете crash dump (моментна снимка) на съдържанието на RAM и го запазете HDD. Има три вида дъмп на паметта:

Пълен дъмп на паметта – запазва цялото съдържание на RAM. Размерът на изображението е равен на размера на RAM + 1 MB (заглавие). Използва се много рядко, тъй като при системи с голямо количество памет размерът на дъмп ще бъде твърде голям.

Дъмп на паметта на ядрото – записва RAM информация, свързана само с режима на ядрото. Информацията за потребителския режим не се запазва, защото не съдържа информация за причината за срива на системата. Размерът на дъмп файла зависи от размера на RAM и варира от 50 MB (за системи с 128 MB RAM) до 800 MB (за системи с 8 GB RAM).

Малък дъмп на паметта (мини дъмп) - съдържа сравнително малко количество информация: код за грешка с параметри, списък с драйвери, заредени в RAM по време на срива на системата и т.н., но тази информация е достатъчна, за да идентифицира дефектния драйвер . Друго предимство на този тип сметище е малък размерфайл.

СИСТЕМНИ НАСТРОЙКИ

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

За Windows Xp

За Windows 7

Моя компютър Имоти
Отидете в раздела Допълнително;
Настроики;
В полето Писане на информация за отстраняване на грешкиизбирам Малък дъмп на паметта (64 KB).

Щракнете с десния бутон върху иконата компютърот контекстното меню изберете Имоти(или клавишната комбинация Win+Pause);
В лявото меню щракнете върху елемента Разширени настройки на системата;
Отидете в раздела Допълнително;
В полето Изтегляне и възстановяване трябва да щракнете върху бутона Настроики;
В полето Писане на информация за отстраняване на грешкиизбирам Малък дъмп на паметта (128 KB).

След като завършите всички манипулации, след всеки BSoD файл с разширение .dmp ще бъде записан в папката C:\WINDOWS\Minidump. Съветвам ви да прочетете материала „Как да създадете папка“. Можете също да поставите отметка в квадратчето „ Сменете съществуващ файлсметище" В този случай всеки нов crash dump ще бъде написан върху стария. Не препоръчвам да го включвате тази опция.

АНАЛИЗИРАНЕ НА ДЪМП ЗА СРИВ С ИЗПОЛЗВАНЕ НА ПРОГРАМАТА BLUESCREENVIEW

И така, след като се появи Синият екран на смъртта, системата записа нов дъмп на паметта за срив. За да анализирате дъмпа, препоръчвам да използвате програмата BlueScreenView. Може да бъде изтеглен безплатно от тук. Програмата е доста удобна и има интуитивен интерфейс. След като го инсталирате, първото нещо, което трябва да направите, е да посочите местоположението за съхраняване на дъмпове на паметта в системата. За да направите това, отидете на елемента от менюто „ Настроики” и изберете „ РазширеноНастроики" Изберете бутона за избор „ ЗаредетеотнаследнотоМини сметищепапка” и посочете папката, в която се съхраняват дъмповете. Ако файловете се съхраняват в папката C:\WINDOWS\Minidump, можете да щракнете върху „ По подразбиране" Щракнете върху OK и стигнете до интерфейса на програмата.

Програмата се състои от три основни блока:

Блок с главно меню и контролен панел;
Списъчен блок crash dumpsпамет;
В зависимост от избраните параметри, той може да съдържа:

списък на всички драйвери в RAM преди да се появи син екран (по подразбиране);
списък с драйвери, намиращи се в RAM стека;
BSoD екранна снимка;
и други стойности, които няма да използваме.

В блока на списъка с дъмпа на паметта (маркиран с номер 2 на фигурата), изберете дъмпа, който ни интересува, и вижте списъка с драйвери, които са били заредени в RAM (маркирани с номер 3 на фигурата). Розов цвятдрайверите, които са били в стека с памет, са оцветени. Те са причината за BSoD. След това отидете в главното меню на драйвера, определете към кое устройство или програма принадлежат. На първо място, обърнете внимание на системни файлове, тъй като системните файлове при всички случаи се зареждат в RAM. Лесно се вижда, че дефектният драйвер в изображението е myfault.sys. Ще кажа, че тази програма беше специално стартирана, за да причини Stop грешка. След като идентифицирате дефектния драйвер, трябва или да го актуализирате, или да го премахнете от системата.

За да може програмата да покаже списък с драйвери, намиращи се в стека на паметта по време на поява на BSoDтрябва да отидете на елемента от менюто „ Настроики„щракнете върху менюто“ НисъкПрозорецРежим” и изберете „ самоШофьориНамеренивСтек” (или натиснете клавиша F7) и за да покажете екранна снимка на грешката, изберете „ СинекранвXPстил” (F8). За да се върнете към списъка с всички драйвери, трябва да изберете „ всичкоШофьори” (F6).

Здравейте приятели, днес ще обсъдим една интересна тема, която ще ви помогне в бъдеще, когато се появи син екран на смъртта (BSoD).

Подобно на мен, много други потребители трябваше да наблюдават появата на екран със син фон, на който пише нещо (бяло на синьо). Това явление показва критичен проблем както в софтуера, например конфликт на драйвери, така и във физическа неизправност на някой компютърен компонент.

Наскоро отново получих син екран в Windows 10, но бързо се отървах от него и скоро ще ви разкажа за това.

Искате ли да гледате филми онлайн в добро качество? След това последвайте връзката.

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

Има три вида дъмп на паметта:

Пълен дъмп на паметта – тази функция ви позволява да запазите напълно съдържанието на RAM. Използва се рядко, защото си представете, че имате 32 GB RAM, с пълен дъмп, целият този обем ще се съхранява на диска.

Дъмп на ядрото – запазва информация за режима на ядрото.

Малък дъмп на паметта – записва малко количество информация за грешки и заредени компоненти, които са присъствали по време на възникване на неизправността на системата. Ще използваме този тип dump, защото ще ни даде достатъчно информация за BSoD.

Местоположението както на малкия, така и на пълния дъмп е различно, например малкият дъмп се намира в следния път: %systemroot%minidump.

Пълният дъмп е тук: %systemroot%.

Има различни програми за анализиране на дъмпове на паметта, но ние ще използваме две. Първият е Microsoft Kernel Debuggers, както подсказва името, помощна програма от Microsoft. Можете да го изтеглите от официалния сайт. Втората програма е BlueScreenView, безплатна програма, изтеглете от тук.

Анализиране на дъмп на паметта с помощта на Microsoft Kernel Debuggers

За различни версии на системи трябва да изтеглите различен тип помощна програма. Например за 64-битова операционна система е необходима 64-битова програма, за 32-битова операционна система е необходима 32-битова версия.

Това не е всичко, трябва да изтеглите и инсталирате пакета от символи за отстраняване на грешки, необходими за програмата. Нарича се символи за отстраняване на грешки. Всяка версия на този пакет също се изтегля под определена операционна система, първо разберете каква система имате и след това изтеглете. За да не се налага да търсите тези символи навсякъде, ето връзката за изтегляне. За предпочитане е инсталацията да се извърши по този път: %systemroot%symbols.

Сега можете да стартирате нашия дебъгер, чийто прозорец ще изглежда така:

SRV*%systemroot%symbols*http://msdl.microsoft.com/download/symbols

Това е всичко. Конфигурирахме програмата по правилния начин, сега започваме да анализираме дъмпове на паметта. В програмата щракнете върху бутона „Файл“, след това върху „Отворете дъмп за срив“ и изберете желания файл.

В прозореца, който се показва, можете да въведете команди. Ако въведем!analyze –v ще получим повече информация.

Това е всичко с тази програма. За да спрете дебъгера, изберете „Debug“ и елемента „Stop Debugging“.

Анализиране на дъмп на памет с помощта на BlueScreenView

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

Изтеглете програмата от връзката по-горе и инсталирайте. След като стартирате помощната програма, трябва да я конфигурирате. Отидете на параметрите: „Настройки“ - „Разширени настройки“. Ще се отвори малък прозорец с няколко елемента. В първия параграф трябва да посочите местоположението на дъмповете на паметта. Те обикновено се намират в пътя C:WINDOWSMinidump. След това просто щракнете върху бутона „По подразбиране“.

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

В интернет можете да намерите всичко за кода на грешката и драйвера, който може да е виновен за BSoD. За да направите това, щракнете върху „Файл“ и след това върху „Намиране на код за грешка + драйвер в Google“.

За да покажете екранната снимка на BSoD, натиснете F8.

За да покажете всички драйвери и файлове, натиснете F6.

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

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

http://computerinfo.ru/analiz-dampa-pamyati/http://computerinfo.ru/wp-content/uploads/2016/08/analiz-dampa-pamyati.jpghttp://computerinfo.ru/wp-content/ uploads/2016/08/analiz-dampa-pamyati-150×150.jpg2016-08-18T13:45:42+00:00EvilSin225ProblemsBlueScreenView,Microsoft Kernel Debuggers, анализ на дъмп, анализ на дъмп памет, анализ на дъмп Windows памет 10, анализ на дъмпа на паметта на Windows 7, анализ на дъмпа на срива, причина за BSoD Здравейте приятели, днес ще разгледаме една интересна тема, която ще ви помогне в бъдеще, когато се появи син екран на смъртта (BSoD). Подобно на мен, много други потребители трябваше да наблюдават появата на екран със син фон, на който пише нещо (бяло на синьо). Това явление показва критичен проблем, както в софтуера, например, ... EvilSin225 Андрей Терехов [имейл защитен]Компютърни технологии

Срив на дъмп

Всички Windows системи, когато се открие фатална грешка, правят crash dump (моментна снимка) на съдържанието на RAM и го записват на твърдия диск. Има три вида дъмп на паметта:

Малък дъмп на паметта (мини дъмп) - съдържа сравнително малко количество информация: код за грешка с параметри, списък на драйверите, заредени в RAM по време на срива на системата и т.н., но тази информация е достатъчна, за да идентифицира дефектния драйвер . Друго предимство на този тип дъмп е малкият размер на файла.

Системни настройки

След като завършите всички манипулации, след всеки BSoD файл с разширение .dmp ще бъде записан в папката C:WINDOWSMinidump. Съветвам ви да прочетете материала „Как да създадете папка“. Можете също да поставите отметка в квадратчето „Замяна на съществуващ дъмп файл“. В този случай всеки нов crash dump ще бъде написан върху стария. Не препоръчвам да активирате тази опция.

Анализиране на дъмп при срив с помощта на BlueScreenView

И така, след като се появи Синият екран на смъртта, системата записа нов дъмп на паметта за срив. За да анализирате дъмпа, препоръчвам да използвате програмата BlueScreenView. Може да бъде изтеглен безплатно от тук. Програмата е доста удобна и има интуитивен интерфейс. След като го инсталирате, първото нещо, което трябва да направите, е да посочите местоположението за съхраняване на дъмпове на паметта в системата. За да направите това, отидете на елемента от менюто „Опции“ и изберете „Разширени опции“. Изберете бутона за избор „Зареждане от следната папка Mini Dump“ и посочете папката, в която се съхраняват дъмповете. Ако файловете се съхраняват в папката C:WINDOWSMinidump, можете да щракнете върху бутона „По подразбиране“. Щракнете върху OK и стигнете до интерфейса на програмата.

Програмата се състои от три основни блока:

В блока на списъка с дъмпа на паметта (маркиран с номер 2 на фигурата), изберете дъмпа, който ни интересува, и погледнете списъка с драйвери, които са били заредени в RAM (маркирани с номер 3 на фигурата). Драйверите, които са били в стека с памет, са оцветени в розово. Те са причината за BSoD. След това отидете в главното меню на драйвера, определете към кое устройство или програма принадлежат. На първо място, обърнете внимание на несистемните файлове, тъй като системните файлове във всеки случай се зареждат в RAM. Лесно се вижда, че дефектният драйвер в изображението е myfault.sys. Ще кажа, че тази програма беше специално стартирана, за да причини Stop грешка. След като идентифицирате дефектния драйвер, трябва или да го актуализирате, или да го премахнете от системата.

За да може програмата да покаже списък с драйвери, намиращи се в стека на паметта, когато възникне BSoD, трябва да отидете в елемента от менюто „Опции“, да щракнете върху менюто „LowerPaneMode“ и да изберете „OnlyDriversFoundInStack“ (или натиснете F7 ключ) и за да покажете екранна снимка на грешката, изберете „BlueScreeninXPStyle“ (F8). За да се върнете към списъка с всички драйвери, трябва да изберете “AllDrivers” (F6).

Ще съм благодарен, ако използвате бутоните:

Анализ на дъмпа при срив на Windows

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

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

Дъмпът за срив може да бъде анализиран с помощта на помощната програма BlueScreenView или системния дебъгер WinDbg (Инструменти за отстраняване на грешки за Windows).

Анализ на дъмпа при срив с помощта на помощната програма BlueScreenView

Най-простият инструмент за анализ на crash dumps е Помощна програма BlueScreenViewот NirSoft.

Изтеглете програмата от уебсайта на разработчика.

BlueScreenView сканира папката minidump и показва информация за откритите грешки.

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

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

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

Анализ на crash dump с помощта на дебъгера WinDbg

Използвайки WinDbg, можете да извлечете по-подробна информация от дъмп за срив, включително препис на стека на повикванията.

Инсталиране на инструменти за отстраняване на грешки за windows (WinDbg)

Microsoft разпространява само WinDbg като част от SDK; можете да изтеглите уеб инсталатора от страницата за изтегляне на Dev Center.

Не е необходима инсталация на SDK за анализиране на изхвърляния при срив. Можете да изтеглите Инструменти за отстраняване на грешки за Windows (WinDbg) като отделен пакет тук или тук.

Изтеглете и инсталирайте WinDbg за вашата версия на Windows. Версията за Windows 7 работи и в Windows XP и Windows Vista.

Windows 10 изисква WinDbg версия 10.0.10586.567. Изтеглете Windows 10 Standalone SDK. По време на инсталацията деактивирайте всички компоненти с изключение на дебъгера.

След инсталацията коригираме прекия път за стартиране на WinDbg. В свойствата на прекия път поставете отметка в квадратчето, за да стартирате като администратор. Също така, като работна папка, задайте: %SystemRoot%Minidump.

Настройка на символи за отстраняване на грешки

Символите за отстраняване на грешки съдържат имена на символни функции от програмен код. Те са необходими за дешифриране и тълкуване на crash dump.

Когато стартирате WinDbg за първи път, трябва да посочите пътя до символи за отстраняване на грешки, за да направите това, отворете менюто "Файл", "Път на файл със символи" или използвайте комбинацията Ctrl+S.

Следващият ред позволява зареждане на символи за отстраняване на грешки от мрежата, задаване на локалния път за записване на файлове и адреса за изтегляне от Интернет:

srv*C:windowssymbols*http://msdl.microsoft.com/download/symbols

Ако системата не е свързана към интернет, инсталационният пакет на символа може да бъде предварително изтеглен от страницата за изтегляне на пакета символи на Windows, Microsoft Development Center.

Анализ на дъмпа при срив

Стартирайте WinDbg.

В менюто изберете File, Open Crash Dump или натиснете Ctrl+D.

Посочете пътя към дъмпа %SystemRoot%MEMORY.DMP или %SystemRoot%Minidumpfile.dmp.

За получаване подробна информацияизпълнете командата:

Дебъгерът ще ви подкани да го изпълните; просто задръжте курсора на мишката върху връзката и щракнете.

В резултат на това получаваме следващ изход:

**************************************** ********** ******************* * * * Анализ на проверка на грешки * * * ************* ********** ****************************** **************** Тип грешка: KMODE_EXCEPTION_NOT_HANDLED (1e) Коментар за грешка: Това е много често срещана проверка на грешка. Обикновено адресът на изключение посочва драйвера/функцията, която е причинила проблема. Винаги отбелязвайте този адрес, както и датата на връзката на драйвера/изображението, което съдържа този адрес. Аргументи: Аргументи за грешка: Arg1: 000000000000000, Кодът на изключение, който не е обработен Arg2: 000000000000000, Адресът, на който е възникнало изключението при Arg3: 000000000000000, Параметър 0 на изключението Arg4: 0000000000000000, Параметър 1 от изключението Подробности за отстраняване на грешки: —— ———— EXCEPTION_CODE: (Win32) 0 (0) — . FAULTING_IP: +3332313336383065 00000000`00000000 ?? ??? EXCEPTION_PARAMETER1: 000000000000000 EXCEPTION_PARAMETER2: 000000000000000 ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0 BUGCHECK_STR: 0x1E_0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: IVER _FAULT Процес, причинил грешката: PROCESS_NAME: VirtualBox.exe CURRENT_IRQL: 2 EXCEPTION_RECORD: fffff80000ba24d8 - (.exr 0xfffff80000ba24d8) ExceptionAddress: fffff800034d8a70 ( nt !DbgBreakPoint) ExceptionCode: 80000003 (Изключение за прекъсване на инструкцията) ExceptionFlags: 00000000 NumberParameters: 1 Параметър: 000000000000000 TRAP_FRAME: fffff80000ba2580 — (.trap 0xfffff80000ba2580) ЗАБЕЛЕЖКА: Рамката за прихващане не съдържа всички регистри. Някои стойности на регистъра може да са нулирани или неправилни. RAX = 0000000000142940 RBX = 0000000000000000 RCX = FFFFA80055BE690 RDX = 0000000000009018 RSI = 000000000000000 RDI = 00000000000000 34D8A71 = 0000000000002274 R9 = 11D0851B22C6AC61 R10 = FFFFF80003464000 R11 = FFFFF80000BA27E0 R12 = 00000000 00000000 R13 = 00000000000000 R14 = iopl=0 nv up ei pl nz ac po nc nt!DbgBreakPoint+0x1: fffff800`034d8a71 c3 ret Нулиране на обхвата по подразбиране LAST_CONTROL_TRANSFER: от fffff800034d85fe до fffff800034e0c10 STACK_TEXT: Извикване на стека ov: fffff800`00ba 15b8 fffff800`034d85fe: fffffa80`03c05530 00000000`ffffffff fffff800`00ba1d30 fffff800`0350c830: nt!KeBugCheck fffff800`00ba15c0 fffff800`0350c4fd: fffff800`036ea71c fffff800`03627c30 fffff800`03464000 fffff800` 00ba 24d8: nt!KiKernelCalloutExceptionHandler+0xe fffff800`00ba15f0 fffff800`0350b2d5: fffff800`0362b028 fffff800`00ba1668 fffff800 ` 00ba24d8 fffff800`03464000: nt!RtlpExecuteHandlerForException+0xd fffff800`00ba1620 fffff800`0351c361: fffff800`00ba24d8 fffff800`00ba1d30 fffff800`0000000000 000 000`00142940: nt! RtlDispatchException+0x415 fffff800`00ba1d00 fffff800`034e02c2: fffff800`00ba24d8 fffffa80`07149010 fffff800`00ba2580 00000000`00000000: nt!KiDispatchException+0x 135 f ffff800`00ba23a0 fffff800`034de0f4: 00000000`00000016 00000000`00000001 00000000`00000001 00000000`00000000: nt ! KiExceptionDispatch+0xc2 fffff800`00ba2580 fffff800`034d8a71: fffff880`05861446 00000000`df029940 fffff880`02f45bec 00000000`deee7000: nt!KiBreakpointTrap+ 0xf4 fff ff800`00ba2718 fffff880`05861446: 00000000`df029940 fffff880`02f45bec 00000000`deee7000 fffff880`01229f06: nt! DbgBreakPoint+0x1 fffff800`00ba2720 00000000`df029940: fffff880`02f45bec 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8: cmudaxp+0x25446 fff ff800` 00ba2728 fffff880`02f45bec: 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8 00000000`00000000: 0xdf029940 fffff800 `00ba2730 00000000`deee7000: fffff880`01229f06 fffffa80`05635af8 00000000`00000000 00000000`00000003: VBoxDrv+0x6bec fffff800`00ba2738 fffff88 0`01229f0 6: fffffa80`05635af8 00000000`00000000 00000000`00000003 fffff880`05865913: 0xdeee7000 fffff800`00ba2740 00000000`00000000 : 00000000` 00000001 00000000`00000006 00000000`00000001 fffff800`00ba2800: CLASSPNP! ClasspServiceIdleRequest+0x26 STACK_COMMAND: kb FOLLOWUP_IP: cmudaxp+25446 fffff 880`05861446 ? ??? SYMBOL_STACK_INDEX: 8 SYMBOL_NAME: cmudaxp+25446 FOLLOWUP_NAME: Driver MachineOwner, в който е възникнала грешката: MODULE_NAME: cmudaxp IMAGE_NAME: cmudaxp.sys DEBUG_FLR_IMAGE_TIMESTAMP: 47906a45 FAILURE_BUCKET_ID: X64_0x1E_0 _cmudax p+25446 BUCKET_ID: X64_0x1E_0_cmudaxp+25446 Последване: MachineOwner ———

Получаване на информация за проблемния драйвер

Ако драйверът с грешката бъде намерен, името на драйвера ще се покаже в полетата MODULE_NAME и IMAGE_NAME.

За да получите пътя на файла и друга информация, щракнете върху връзката към модула:

начало край име на модул fffff880`0583c000 fffff880`059ef000 cmudaxp T (без символи) Зареден файл с изображение на символ: cmudaxp.sys Път на изображение: SystemRootsystem32driverscmudaxp.sys Име на изображение: cmudaxp.sys Времево клеймо: петък, 18 януари 13:58:45 2008 (47906A45) Контролна сума: 0013077F Размер на изображението: 001B3000 Преводи: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Ако пълен пъткъм драйвера не е указано, папката по подразбиране е %SystemRoot%system32drivers.

Намираме посочен файл, и изучавайте неговите свойства.

Ние актуализираме проблемния драйвер.

Хардуерни причини за критични грешки

Източникът на критични грешки често е неизправност в дисковата подсистема или подсистемата на паметта.

Диагностика на повреди на диска

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

За да изключите проблеми с диска, проверете syslogсъбития за грешки при четене и запис на диск.

Проверка на S.M.A.R.T параметрите харддиск, можете да ги получите например с помощта на програмата SpeedFan.

Обръщаме специално внимание на следните параметри: „Текущ брой сектори в очакване“ и „Брой некоригируеми сектори“; ненулевите стойности на тези параметри показват повреда на диска.

Ненулева стойност на параметър: „Брой на грешки при CRC UltraDMA“ показва проблем със SATA кабела.

Научете повече за опциите на S.M.A.R.T. прочетете в статията в Уикипедия.

Диагностициране на проблеми с паметта

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

Можете да идентифицирате проблеми с паметта с помощта на помощната програма Memtest86+.

Започвайки с Windows Vista, системата има собствен тест за памет. За да го стартирате, щракнете върху „Старт“, въведете „памет“ в лентата за търсене, изберете „Инструмент за диагностика на паметта на Windows“.

Проблемите с паметта в някои случаи могат да бъдат разрешени чрез актуализиране на BIOS.

Конфигуриране на опции за запазване на crash dump

За да промените настройките за запазване на дъмп при срив, щракнете върху бутона „Старт“, щракнете върху „Компютър“ Кликнете с десния бутонмишки, в контекстно менюизберете „Свойства“. В прозореца „Система“ вляво изберете „Разширени системни настройки“, в групата „Зареждане и възстановяване“ щракнете върху бутона „Опции“.

Прочетете повече за изхвърлянията на паметта тук.

Син екран на смъртта - какво да правите и как да идентифицирате грешката

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

Видове дъмпи

Има три вида дъмп:

За да може системата да спести малък дъмп, е необходимо да зададете определени параметри.

За Windows 7 и Windows XP OS

Щракнете върху „Старт“, щракнете с десния бутон върху „Компютър“ и изберете „Свойства“.

Отидете в секцията „Разширени системни настройки“.

Появява се прозорецът System Properties. В раздела „Разширени“, в секцията „Зареждане и възстановяване“, щракнете върху „Опции“.

Изберете „Small memory dump“ и щракнете върху „Ok“, за да запазите промените.

Анализиране на малък дъмп с помощта на програмата Син екранПреглед

Програмата Blue Screen View се изтегля като архив тук и не изисква инсталация. За да го използваме за определяне на причината за повредата на системата, изпълняваме следните стъпки.

Стартираме приложение в архива, което е идентично с името на програмата.

Ще се отвори софтуерен прозорец. Интерфейсът е прост, но на английски. На първо място, посочваме мястото за запазване на малкото сметище. Щракнете върху „Опции“ и изберете „Разширени опции“.

Поставете отметка до първия раздел „Зареждане от следната папка Mini Dump“ и посочете папката, където се намира моментната снимка на грешката. Ако първоначално е зададен малък дъмп в системните настройки, самата програма ще посочи пътя до моментната снимка C: WINDOWSMinidump. Щракнете върху „Ok“, за да стигнете до интерфейса на програмата.

Блокът с номер 1 е списък с изхвърляния при срив, направени от системата. Под номер 2 има снимки и списък с драйвери.

Драйверите, които причиняват повреда на системата, са обозначени в розово в списъка.

Ако нямате списък с драйвери, щракнете върху „Опции“. Отидете на „LowerPaneMode“ и изберете „OnlyDriversFoundInStack“.

След като определихме кой драйвер е неуспешен, ние отстраняваме проблема.

Как да използвате дъмп на паметта, за да определите драйвера, причиняващ BSOD

Причина за критична windows грешки, придружен със сини екрани (BSOD), често е драйвер - новоинсталиран или повреден. След като определите кой драйвер причинява грешката, можете да започнете да коригирате проблема: актуализирайте драйвера, върнете се към по-ранна версия, преинсталирайте или премахнете приложението, което е инсталирало драйвера и т.н. Името на драйвера не винаги се показва в синьо екран. Има обаче много прост начин, който ви позволява да идентифицирате проблемния драйвер за няколко минути, като използвате дъмп на паметта.

Стъпка 1 - Активиране на запис на дъмп памет

Първо трябва да се уверите, че записът на дъмп е активиран. За да направите това, отворете свойствата на системата, като натиснете клавишната комбинация Win+Pause, [във Vista щракнете върху връзката Разширени системни настройки], отидете на раздела Разширени и накрая щракнете върху бутона Стартиране и възстановяване.

Малките дъмпове на паметта трябва да са достатъчни за нашите цели.

Обърнете внимание на пътя до папката, където ще бъдат записани, ако възникне критична грешка.

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

Стъпка 2 - Изтеглете и инсталирайте диагностични инструменти

Не е толкова страшно, колкото си мислите :)

Стъпка 3 - Анализиране на дъмпа на паметта

Сега всичко се свежда до изпълнение на една команда. Отворете командния ред и отидете до папката, в която сте извлекли kdfe.cmd. Стартирайте файла, като посочите пътя до файла с дъмп на паметта като параметър (в примера по-долу файлът се нарича Mini1110307-01.dmp)

kdfe.cmd "%systemroot%MinidumpMini1110307-01.dmp"

След минута ще видите резултата.

Драйверът, причинил грешката, е идентифициран!

Допълнителни ресурси

Колко често трябва да гледате екрана? смъртта на Windows(BSoD)? BSoD може да възникне в различни случаи: както вече при работа със системата, така и по време на зареждането на операционната система. Как да определите какво причинява BSoD и да коригирате този проблем? операционна Windows системае в състояние да запише дъмп на паметта, когато възникне грешка, така че Системен администраторможе да анализира дъмп данните и да намери причината за BSoD.

Има два вида дъмпове на паметта - малък (минидъмп) и пълен. В зависимост от настройките на операционната система, системата може да запише пълни или малки дъмпове или да не предприеме никакви действия, когато възникне грешка.

Край пътеката има малко сметище %systemroot%\minidumpи има име като Minixxxxxx-xx.dmp
Пълното бунище се намира покрай пътеката %systemroot%и има име като Memory.dmp

За да анализирате съдържанието на дъмповете на паметта, трябва да използвате специална полезност- Microsoft Kernel Debugger.
Можете да получите програмата и компонентите, необходими за нейната работа, директно от сайта на Microsoft - Debugging Tools

Когато избирате дебъгер, трябва да вземете предвид версията на операционната система, на която ще трябва да анализирате дъмпове на паметта. За 32-битова ОС е необходима 32-битовата версия на дебъгера, а за 64-битова ОС е за предпочитане да използвате 64-битовата версия на дебъгера.

В допълнение към самия пакет Инструменти за отстраняване на грешки за Windows ще ви е необходим и набор от символи за отстраняване на грешки - Debugging Symbols. Наборът от символи за отстраняване на грешки е специфичен за всяка операционна система, на която е записан BSoD. Следователно ще трябва да изтеглите набор от символи за всяка операционна система, чиято работа ще трябва да анализирате. 32-битов Windows XP ще изисква 32-битов набор от знаци на Windows XP; 64-битова ОС ще изисква 64-битов набор от знаци на Windows XP. За други ОС Семейство Windowsнаборите от знаци се избират по същия принцип. Можете да изтеглите символи за отстраняване на грешки от тук. Препоръчително е да ги инсталирате на %systemroot%\символи

След като инсталирате програмата за отстраняване на грешки и символите за отстраняване на грешки, стартирайте програмата за отстраняване на грешки. Прозорецът на програмата за отстраняване на грешки след стартиране изглежда така.

Преди да анализирате съдържанието на дъмп на паметта, ще трябва да малка настройкадебъгер. По-конкретно, кажете на програмата къде да търси символи за отстраняване на грешки. За да направите това, изберете от менюто File > Symbol File Path... Щракнете върху бутона Browse... и посочете папката, в която сме инсталирали символите за отстраняване на грешки за въпросния дъмп на паметта.

Можете да поискате информация за необходимите символи за отстраняване на грешки директно от Интернет, с публичен сървър Microsoft. Така ще имате най-много нова версиягерои. Можете да направите това по следния начин - в менюто File > Symbol File Path… въведете: SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols

След като посочите пътя до символите за отстраняване на грешки, изберете File > Save workspace от менюто и потвърдете действието, като щракнете върху OK.

За да започнете да анализирате дъмпа на паметта, изберете File > Open Crash Dump... от менюто и изберете файла, необходим за проверка.

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

Командата !analyze -v, дадена на дебъгера в командна линия, ще покаже по-подробна информация.

Можете да спрете отстраняването на грешки, като изберете елемента от менюто Debug > Stop Debugging

По този начин, като използвате пакета Инструменти за отстраняване на грешки за Windows, винаги можете да получите доста пълна картина на причините за системни грешки.