Разрешаване на пълен дъмп на паметта в Windows 7. Анализиране на дъмп на паметта

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

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

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

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

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

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

За Windows XP За Windows 7
  1. Моя компютър Имоти
  2. Отидете в раздела Освен това;
  3. Настроики;
  4. В полето Писане на информация за отстраняване на грешкиизбирам Малък дъмп на паметта (64 KB).
  1. Щракнете с десния бутон върху иконата Компютърот контекстното меню изберете Имоти(или клавишната комбинация Win + Pause);
  2. В лявото меню щракнете върху елемента Допълнителни системни параметри;
  3. Отидете в раздела Освен това;
  4. В полето Startup and Recovery щракнете върху бутона Настроики;
  5. В полето Писане на информация за отстраняване на грешкиизбирам Малък дъмп на паметта (128 KB).

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

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

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

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

  1. Блок от главно меню и контролен панел;
  2. Блок на списъка с аварийни дъмпове на паметта;
  3. В зависимост от избраните параметри, той може да съдържа:
  • списък на всички драйвери в RAM преди да се появи синият екран (по подразбиране);
  • списък с драйвери, разположени в стека RAM;
  • BSoD екранна снимка;
  • и други стойности, които няма да използваме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BSOD декриптиране

Нека първо да анализираме какво означава това съкращение, BSOD от английския син екран на смъртта или режим СТОП грешка.

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

Как да персонализирате създаването на дъмп на паметта

По подразбиране Windows със син екран създава crash dump файл memory.dmp, сега ще покажа как е конфигуриран и къде се съхранява, ще го покажа като използвам Windows Server 2008 R2 като пример, тъй като наскоро имах задача да проучи проблема със синия екран във виртуална машина. За да разберете къде са конфигурирани прозорците с дъмп памет, отворете старт и щракнете с десния бутон върху иконата на компютъра и изберете свойства.

Как да анализирате синия екран на изхвърляне на паметта в Windows - Компютърни свойства

Как да анализирате паметта за изхвърляне на синия екран в системните настройки на Windows

Отидете в раздела Разширено зареждане и възстановяване. Щракнете върху бутона Опции

Как да анализирате синия екран на изхвърляне на паметта в Windows - зареждане и възстановяване

Къде се съхранява файлът memory.dmp

и виждаме, че първо има квадратче за отметка за извършване на автоматично рестартиране, за записване на информация за отстраняване на грешки, избрано е дъмп на паметта на ядрото и по-долу е мястото, където се записва дъмпът на паметта% SystemRoot% \ MEMORY.DMP

Нека отидем в папката c: \ windows \ и намерим файла MEMORY.DMP, който съдържа синия екран с кодове за смърт

Как да анализирате синия екран на дъмп паметта в Windows-memory.dmp

Как да настроите мини дъмп

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

Съхранява се в папката c: \ windows \ minidump. Предимството е, че заема по-малко място и се генерира в отделен файл за всеки син екран. Винаги можете да видите историята на случаите на син екран.

Сега, когато разбрахме къде да намерим файла за изхвърляне на паметта, трябва да се научим как да го интерпретираме и да разберем причината зад синия екран на смъртта. Microsoft Kernel Debugger ще ни помогне да решим този проблем. Можете да изтеглите Microsoft Kernel Debugger от официалния уебсайт, основното е да изберете необходимата версия на ОС, ако някой се е счупил, можете да го изтеглите от диска на Yandex, като използвате директна връзка. Той също е част от ADK.

Изтеглете Microsoft Kernel Debugger, като резултат ще имате малък файл, който ще ви позволи да изтеглите всичко необходимо от Интернет. Пускаме го.

няма да участваме в програмата за подобряване на качеството

щракнете върху Приемам и се съгласете с лиценза

Как да инсталирате Microsoft Kernel Debugger - ние сме съгласни с лиценза

ще започне инсталирането на Microsoft Kernel Debugger

Как да инсталирате Microsoft Kernel Debugger - Инсталирайте MKD

Виждаме, че Microsoft Kernel Debugger е инсталиран успешно

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

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

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

След като инсталирате Debugging Symbols под системата, на която имаше син екран на смъртта, стартирайте Debugging Tools

Как да инсталирате Microsoft Kernel Debugger-Run

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

Щракнете върху бутона Преглед....

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

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

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

Малко сметище се намира покрай пътеката % systemroot% \ minidumpи има име като Minixxxxxx-xx.dmp
Цялото сметище се намира по протежение на пътеката % корен на систематаи има име като Memory.dmp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Има три типа изхвърляния на паметта:

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

Dump на ядрото - запазва информация за режима на ядрото.

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

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

Пълният дъмп може да бъде намерен тук:% systemroot%.

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

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

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

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

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

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

Програмата ви позволява да извличате символи директно от мрежата, така че дори не е нужно да ги изтегляте (съжалявам на тези, които вече са изтеглили). Те ще се занимават със сървъра на Microsoft, така че всичко е безопасно. Така че, трябва да отворите отново "File", след това "Symbol File Path" и въведете следната команда:

SRV *% systemroot% символи * http: //msdl.microsoft.com/download/symbols

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

Това е всичко. Настроихме програмата по правилния начин, сега започваме да анализираме дъмповете на паметта. В програмата натиснете бутона "Файл", след това "Open Crash Dump" и изберете желания файл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Краш дъмп на паметта

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ на срива на Windows

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

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

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

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

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

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

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

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

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

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

Анализ на crash dump с WinDbg дебъгер

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

Инсталиране на инструменти за отстраняване на грешки за 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. Изтеглете изолирания комплект за разработване на софтуер (SDK) за Windows 10. Уеб инсталаторът ще бъде изтеглен. По време на инсталацията деактивирайте всички компоненти с изключение на дебъгера.

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

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

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

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

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

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

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

Анализ на срива

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

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

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

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

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

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

************************************************** * ****************************** * * * Анализ на проверка на грешки * * * ************* ************************************************** * *************** Тип грешка: KMODE_EXCEPTION_NOT_HANDLED (1e) Коментар за грешка: Това е много често срещана проверка на грешки. Обикновено адресът на изключението посочва драйвера/функцията, която е причинила проблема. Винаги отбелязвайте този адрес, както и датата на връзката на драйвера/изображението, което съдържа този адрес. Аргументи: Аргументи за грешка: Arg1: 0000000000000000, Кодът на изключението, който не е бил обработен Arg2: 0000000000000000, Адресът, на който е възникнало изключението при Arg3: 0000000000000000, Параметър 00 на изключението: Debu000, Параметър 00 на изключението — Параметър 00 на изключението: 0 ———— EXCEPTION_CODE: (Win32) 0 (0) -. FAULTING_IP: +3332313336383065 00000000`00000000 ?? ??? EXCEPTION_PARAMETER1: 0000000000000000 EXCEPTION_PARAMETER2: 0000000000000000 ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0 BUGCHECK_STR: 0x1E_0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: процес VISTA_DRIVER_FAULT Faulting: PROCESS_NAME: VirtualBox.exe CURRENT_IRQL: 2 EXCEPTION_RECORD: fffff80000ba24d8 - (.exr 0xfffff80000ba24d8) ExceptionAddress: fffff800034d8a70 (NT DbgBreakPoint ) ExceptionCode: 80000003 (Изключение на инструкциите за прекъсване) ExceptionFlags: 00000000 NumberParameters: 1 Параметър: 0000000000000000 TRAP_FRAME: fffff80000ba2580 - (.trap0000000000000000000000000000000000- (.trap0000000000000) - (.trap 000000000000000) Някои стойности на регистъра може да са нулирани или неправилни. Rax = 0000000000142940 RBX = 0000000000000000 RCX = fffffa80055be690 RDX = 0000000000009018 RSI = 0000000000000000 RDI = 0000000000000000 RIP = fffff800034d8a71 RSP = fffff80000ba2718 RBP = fffff88006fa0000 R8 = 0000000000002274 R9 = 11d0851b22c6ac61 R10 = fffff80003464000 R11 = fffff80000ba27e0 R12 = 0000000000000000 R13 = 0000000000000000 R14 = 0000000000000000 R15 = 0000000000000000 iopl = 0 NV до EI пл NZ ав PO NC нт DbgBreakPoint + 0x1: fffff800`034d8a71 c3 задържане нулирането подразбиране обхват LAST_CONTROL_TRANSFER: от fffff800034d85fe да fffff800034e0c10 наричаме стека fffff800034e0c10 STACK0015baff8ff8ff`0000 fffff800`00ba1d30 fffff800`0350c830: NT KeBugCheck fffff800`00ba15c0 fffff800`0350c4fd :! fffff800`036ea71c fffff800`03627c30 fffff800`03464000 fffff800`00ba24d8: нт KiKernelCalloutExceptionHandler + 0xe fffff800`00ba15f0 fffff800`0350b2d5 :! fffff800`0362b028 fffff800`00ba1668 fffff800` 00ba24d8 fffff800`03464000: NT RtlpExecuteHandlerForException + 0xd fffff800` 00ba1620 fffff800`0351 c361: fffff800`00ba24d8 fffff800`00ba1d30 fffff800`00000000 00000000`00142940: nt! RtlDispatchException + 0x415 fffff800`00ba1d00 fffff800`034e02c2: fffff800`00ba24d8 fffffa80`07149010 fffff800`00ba2580 00000000`00000000: NT KiDispatchException + 0x130000000000000000000KiExceptionDispatch + 0xc2 fffff800`00ba2580 fffff800`034d8a71: fffff880`05861446 00000000`df029940 fffff880`02f45bec 00000000`deee7000 : нт KiBreakpointTrap + 0xf4 fffff800`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 fffff800`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 fffff880`01229f06: fffffa80`05635af8 000 00000`00000000 00000000`00000003 fffff880`05865913: 0xdeee7000 fffff800`00ba2740 00000000`00000000: 00000000`00000001 00000000`00000006 00000000`00000001 fffff800`00ba2800:! CLASSPNP ClasspServiceIdleRequest + 0xAND626 STACKbIPff ??? SYMBOL_STACK_INDEX: 8 SYMBOL_NAME: cmudaxp + 25,446 FOLLOWUP_NAME: MachineOwner водача в който възникне грешка: MODULE_NAME: cmudaxp IMAGE_NAME: cmudaxp.sys DEBUG_FLR_IMAGE_TIMESTAMP: 47906a45 FAILURE_BUCKET_ID: X64_0x1E_0_cmudaxp + 25,446 BUCKET_ID: X64_0x1E_0_cmudaxp + 25,446 последващ: MachineOwner ---

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

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

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

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

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

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

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

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

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

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

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

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

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

Обърнете специално внимание на параметрите: "Current Pending Sector Count" и "Uncorrectable Sector Count", различни от нула стойности на тези параметри сигнализират за повреда на диска.

Ненулева стойност на параметъра: "UltraDMA CRC Error Count", показва проблем със SATA кабела.

Повече за параметрите на S.M.A.R.T. прочетете в статията на Wikipedia.

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

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

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

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

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

Конфигуриране на опции за запазване на аварийно изхвърляне

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

Прочетете повече за дъмповете на паметта тук.

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

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

Типове изхвърляне

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

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

За windows 7 и windows XP

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

Преминаваме към секцията "Допълнителни системни параметри".

Появява се прозорецът Свойства на системата. В раздела „Разширени“ в секцията „Стартиране и възстановяване“ щракнете върху „Опции“.

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

Анализ на малък дъмп с изглед на син екран

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ще видите резултата след минута.

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

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