Срив на дъмп. Windows crash dump Какво означава dump memory

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

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

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

Колкото по-точно съдържанието на дъмпа отразява състоянието на паметта в момента на повредата, толкова повече ще можем да анализираме аварийната ситуация. Ето защо е изключително важно да получите точно текущото копие на физическата памет на системата в строго определен момент от времето, непосредствено преди повредата. И единственият начин да направите това е да създадете пълен crash dump. Причината е доста тривиална - когато възникне crash dump на системната памет, било в резултат на повреда, било в резултат на изкуствено симулирана ситуация, системата в този момент на получаване на управление на аварийни функции (KeBugCheckEx) е в абсолютно непроменено (статично) състояние, следователно между момента на възникване на срива и момента, в който данните се записват на носителя, нищо не променя съдържанието на физическата памет и те се записват на диска в първоначалното си състояние. Е, това е на теория, но понякога в живота, но има ситуации, при които поради дефектни хардуерни компоненти самият дъмп на паметта може да бъде повреден или станцията може да замръзне по време на процеса на запис на дъмпа.

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

Теоретично, статичността (неизменността) на "отпечатъка" на паметта се обяснява с факта, че когато се извика функцията KeBugCheckEx, която показва информация за срива и стартира процеса на създаване на дъмп на паметта, системата вече е напълно спряна и съдържанието на физическата памет се записва в блоковете, заети на диска от файла за пейджинг, след което, вече по време на последващото зареждане на операционната система, то се изхвърля във файл на системния носител. Е, почти веднъж наблюдавах ситуация, когато се провали дънна платкапредотврати запазването на дъмпа на паметта: а) замразяване на логиката за запазване на дъмпа по време на работа (процесът не достигна 100%), б) повреждане на файла за дъмп на паметта (дебъгерът проклина структурите), в) запис на файлове за дъмп на memory.dmp на нулева дължина. Следователно, въпреки факта, че системата вече е била напълно спряна по време на създаването на дъмпа на паметта и работи само аварийният код, дефектният хардуер може да направи свои собствени корекции на всяка логика без изключение на всеки етап от работата.
Традиционно, в началния етап, за да запазите дъмп на паметта на Windows, се използват дискови блокове, разпределени за файла за виртуална памет (pagefile). След това, след син екран и рестартиране, данните се преместват в отделен файл, а след това файлът се преименува с шаблон въз основа на типа дъмп. Въпреки това, започвайки от версията Windows Vista, това състояние на нещата може да бъде променено, сега на потребителя се дава възможност да запази избран дъмп без участието на файла за пейджинг, като постави информация за повредата във временен файл. Това беше направено, за да се елиминират грешки в конфигурацията, свързани с неправилна настройкаразмера и позицията на файла за пейджинг, което често води до проблеми в процеса на запазване на дъмп на паметта.
Нека да видим какви типове дъмпове ни позволява да създаваме операционната система Windows:

• Дъмп на паметта на процеса (приложение);
• Дъмп на паметта на ядрото;
• Пълен дъмп на паметта (дъмп на наличната част от физическата памет на системата).

Всички crash dumps могат да бъдат разделени на две основни категории:

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

Конфигурация на дъмп на ядрото

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

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

1. Кликнете Кликнете с десния бутонмишката върху иконата "Моят компютър" - "Свойства" - " Допълнителни опциисистеми“ – „Разширени“.
2. Бутон "Старт" - "Контролен панел" - "Система" - "Разширени системни настройки" - "Разширени".
3. Клавишна комбинация "Windows" + "Пауза" - "Разширени системни настройки" - "Разширени".
4. 
   controlsystem.cpl,3
5. Стартирайте в командния ред (cmd):
   SystemPropertiesAdvanced

Резултатът от описаните действия е да отворите прозореца "Свойства на системата" и да изберете раздела "Разширени":

След това в секцията „Изтегляне и възстановяване“ кликваме, избираме „Опции“ и по този начин отваряме нов прозорец, наречен „Изтегляне и възстановяване“:

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

1. Записване на събития в системния журнал.
2. Извършете автоматично рестартиране.
3. Записване на информация за отстраняване на грешки.
4. Dump файл.
5. Замяна на съществуващ дъмп файл.

Както можете да видите, много от параметрите от списъка са доста тривиални и лесни за разбиране. Бих искал обаче да се спра по-подробно на параметъра "Dump file". Параметърът е представен като падащ списък и има четири възможни стойности:

Малък дъмп на паметта

Малък дъмп на паметта (minidump) е файл, който съдържа най-малко информация за сривове. Най-малкото от всички възможни дъмпове на паметта. Въпреки очевидните недостатъци, често минисметките се използват като информация за повреда за прехвърляне към доставчик на драйвери на трета страна за по-нататъшно проучване.
Съединение:

• Съобщение за грешка.
• Стойност на грешката.
• Опции за грешка.
• Контекст на процесора (PRCB), който е неуспешен.
• Информация за процеса и контекст на ядрото (EPROCESS) за процеса, причиняващ срива, с всичките му нишки.
• Информацията за процеса и контекста на ядрото (ETHREAD) за нишката, причинила срива.
• Стекът на режима на ядрото за нишката, която е причинила срива.
• Списък на заредените драйвери.

Настаняване: %SystemRoot%\Minidump\MMDDYY-XXXXX-NN.dmp. Където MMDDYY е съответно месецът, денят и годината, NN е серийният номер на дъмпа.
Обем: Размерът зависи от битовостта на операционната система: необходими са само 128 килобайта за 32-битова ОС и 256 килобайта за 64-битова ОС във файла за виртуална памет (или във файла, посочен в DedicatedDumpFile). Тъй като не можем да зададем толкова малък размер, го закръгляме до 1 мегабайт.

Дъмп на паметта на ядрото

Този тип дъмп съдържа копие на цялата памет на ядрото към момента на срива.
Съединение:

• Списък на изпълняваните процеси.
• Състоянието на текущата нишка.
• Страниците с памет в режим на ядрото присъстват във физическата памет по време на срива: памет на драйвера в режим на ядрото и програмна памет в режим на ядрото.
• Hardware-Aware Layer (HAL) памет.
• Списък на заредените драйвери.

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

Размер: Варира в зависимост от размера на адресното пространство на ядрото, разпределението на операционната система и броя на драйверите за режим на ядрото. Обикновено се изисква около една трета от количеството физическа памет в суап файла (или файла, посочен от DedicatedDumpFile). Може да варира.

Пълен дъмп на паметта

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

• Всички страници от "видимата" физическа памет. Това е практически цялата памет на системата, с изключение на областите, използвани от хардуера: BIOS, PCI пространство и др.
• Обработка на данни, които са били изпълнявани в системата по време на срива.
• Страници от физическа памет, които не са картографирани във виртуалното адресно пространство, но които могат да помогнат при разследване на причината за повредата.

Пълният дъмп на паметта не включва по подразбиране области от физическа памет, използвани от BIOS.
Местоположение: %SystemRoot%\MEMORY.DMP. Предишният дъмп е презаписан.
Размер: Файлът за виртуална памет (или файлът, посочен в DedicatedDumpFile) изисква размер, равен на размера на физическата памет + 257 мегабайта (тези 257 MB са разделени на някакъв вид заглавка + данни на драйвера). Всъщност в някои операционни системи долният праг на файла за виртуална памет може да бъде зададен точно на стойността на размера на физическата памет.

Автоматичен дъмп на паметта

Стартирайки от Windows 8/ Windows сървър 2012 г. в системата беше въведен нов тип дъмп, наречен "Автоматичен дъмп на паметта", който е зададен като тип по подразбиране. В този случай системата сама решава кой дъмп на паметта да запише в ситуация на определена повреда. Освен това логиката на избор зависи от много критерии, включително честотата на "падането" на операционната система.

След като промените конфигурацията на дъмпа на паметта на Windows, може да се наложи да рестартирате компютъра си.

Настройки на регистъра

Ключът на системния регистър, който дефинира настройките за изхвърляне на данни при срив:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Настроики:

Ръчно създаване на дъмп на паметта

По-горе описахме настройките за автоматично създаванеизхвърляния на системата при срив в случай на критична грешка, тоест необработено изключение в кода на ядрото. Но в Истински живот, в допълнение към срива на операционната система, има ситуации, когато трябва да получите дъмп на системната памет в определен момент от време. Как да бъдем в този случай? Има методи за незабавно получаване на копие на цялата физическа памет, като например използването на командата .dump в програмите за отстраняване на грешки на WinDbg/LiveKD. LiveKD е програма, която ви позволява да стартирате дебъгера на ядрото Kd на работеща система в локален режим. Дебъгерът WinDbg също има подобна функция. Въпреки това, методът в движение за получаване на дъмп не е точен, тъй като дъмпът е създаден в този случай е „непоследователен“, тъй като отнема време за създаване на дъмп и в случай на използване на дебъгер в режим на ядрото , системата продължава да работи и да прави промени в страниците с памет.

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

Фактът, че деактивирате изхвърлянето на паметта, няма да повлияе по никакъв начин на производителността на системата. Когато използвате компютър, системата няма достъп до дъмпа, независимо дали е включен или не. Записът става само когато Windows е "доведен" до BSOD ( син екран). Продължава няколко секунди.

Видове дъмп

За общо развитие, нека се запознаем с видовете сметище. Има три от тях: малък дъмп, core dump и голям. Малък дъмп съхранява най-важната информация за даден проблем. Разработчиците буквално трябва да го сглобят малко по малко. За малък дъмп трябва да отделите 2 MB виртуална памет (файл за пейджинг).

Основен дъмп- най-често срещаният тип сметище. Обикновено това е опцията по подразбиране. Той си записва цялата памет, която е разпределена за ядрото - състоянието на работещите драйвери и данните на хардуерно зависимо ниво. За него трябва да отделите около 30% от общата RAM памет. Например, ако имате 2 GB DDR, тогава разпределете около 700 MB за суап файла.

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

В Windows 7 опциите за дъмп са скрити доста дълбоко. Въведете в лентата за търсене в менюто " Започнете"дума" система", Например.

Изберете резултат " Система". Ще се отвори прозорец. Горе вдясно има списък с опции, изберете последната там - “ Допълнителни системни настройки».

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

Настройване на дъмп на паметта.

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

Конфигуриране на дъмпове на паметта за грешки на Windows

За да видите и конфигурирате, например, да увеличите дъмпа на паметта на Windows, помислете за 7-та версия - тя продължава да бъде популярна. Да, и в други версии се прави по подобен начин. За да направите това, можете да щракнете с десния бутон върху иконата "Моят компютър" и да изберете "Свойства". Можете да отидете по друг начин - отидете на "Контролен панел" и изберете "Система". Така или иначе ще се отвори същият прозорец. След това изберете елемента „Разширени системни настройки“ вляво и в малкия прозорец, който се показва, отидете в раздела „Разширени“. Тук, в секцията „Изтегляне и възстановяване“, щракнете върху бутона „Опции“.

1. Малък дъмп - обемът му е само 256 kb, там се записва само най-общата информация.
2. Дъмп на паметта на ядрото - състоянието е написано тук различни програмив момента на повреда за едно процесорно ядро. Размерът на файла е около 33% от общата налична RAM. Има полезна информация, което ви позволява да идентифицирате причината за повредата, но не е много.
3. Пълният дъмп е копие на цялата RAM и размерът на файла ще бъде равен на неговия обем. Тук можете да намерите каквото пожелаете. Такъв дъмп се създава и при преминаване в режим на хибернация - цялото съдържание на RAM паметта просто се записва на твърдия диск и когато включите компютъра, той продължава да работи от същото място.

В по-новите версии на Windows има режим "Автоматично разтоварване на паметта" - можете да го изберете и това ще бъде напълно достатъчно. Както можете да видите, настройването на дъмп на паметта в Windows 7 е лесно. Ще се пише само при повреди и по никакъв начин не засяга работата на системата.

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

Когато се провали и се създаде нов файлс доклад за проблем, все пак трябва по някакъв начин да го отворите и да разберете какво пише в него. Файлът има разширение dmp, но вградените инструменти за отварянето му са неудобни и могат да бъдат достъпни от командния ред. Между другото, системата запазва този файл в своята папка. Как да отворя файл с дъмп памет с разширение dmp? За да направите това, има различни помощни програми, включително тези от Microsoft, например Microsoft Kernel Debuggers. Може да бъде изтеглен напълно безплатно от официалния сайт, но трябва да прецените дали имате нужда от 32-битова или 64-битова версия. Тази програма може да отваря дъмп файлове на паметта, които се намират в системна папкаи прегледайте съдържанието им под формата на дешифриране. Разбира се, информацията е чисто специфична и е предназначена за специалисти.

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

Как да изтриете файл с дъмп памет

Могат ли изобщо да се премахнат? Да, те са само служебна информация за допълнителен анализ. Ако вече са били прегледани или не са необходими, тогава те могат да бъдат изтрити от по прост начин- Добави в кошницата. В противен случай те постепенно се натрупват и започват да заемат много място на твърдия диск, особено ако се прави пълно копие. оперативна памет. Разбира се, ръчното търсене и изтриване на всички тези файлове не е много приятна задача. Следователно можете да използвате всяка помощна програма за почистване на диск, дори вградена в Windows, като поставите отметка там „Изтриване системни файлове". Когато приключи, всички дъмпове също ще бъдат изтрити. Самата система не използва тези файлове и премахването им е напълно безопасно.

В Windows 8 Microsoft представи нов дъмп на паметта, опцията за автоматично изхвърляне на паметта. Тази опция е зададена по подразбиране в операционната система. Windows 10 представи нов тип дъмп файл, наречен активен дъмп на паметта. За тези, които не знаят, в Windows 7 имаме малък дъмп, дъмп на ядрото и пълен дъмп на паметта. Може би се чудите защо Microsoft реши да създаде тази нова опция за дъмп на паметта? Според Робърт Симпкинс, старши инженер по поддръжката, автоматичен дъмп на паметта може да създаде поддръжка за "системна" страница в конфигурационен файл.
Системата за управление на конфигурацията на файла на страницата е отговорна за управлението на размера на файла на страницата - това избягва прекомерното пространство за глава или размера на файла на страницата. Тази опция е въведена главно за компютри, които работят на SSD устройства, които обикновено са по-малки, но имат огромно количество RAM.

Опции за дъмп на паметта

Основното предимство на "Automatic Memory Dump" е, че ще позволи на сесията на подсистемата в Process Manager автоматично да намали суап файла до размер, по-малък от размера на RAM. За тези, които не знаят, сесията на мениджъра на подсистемата е отговорна за инициализацията на системата, средата за стартиране на услугите и процесите, които са необходими на потребителя, за да влезе в системата. Основно настройва страницата с файлове на виртуална памети стартира процеса winlogon.exe.

Ако искате да промените настройките за автоматичен дъмп на паметта, ето как да го направите. Кликнете ключове за windows+ X и изберете - Система. След това кликнете върху бутона "Разширени системни настройки". Предварително Система Настройки”.

Щракнете върху бутона Разширени системни настройки.

Тук можете да видите падащо меню, където пише „Разширени“.

Тук можете да изберете желаната опция. Предложени опции:

Няма изхвърляния на паметта.
Малък дъмп на паметта.
Дъмп на паметта на ядрото.
Пълен дъмп на паметта.
Автоматичен дъмп на паметта. Добавен в Windows 8.
Дъмп на активната памет. Добавен към Windows 10.
Местоположението на файла с дъмп на паметта във файла %SystemRoot%\MEMORY.DMP.

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

нарича се "LastCrashTime".

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

Windows 10 представи нов дъмп файл, наречен Active Memory Dump. Той съдържа само най-необходимото и затова е по-малък.

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

Можете да анализирате дъмпа на паметта на Windows.dmp файлове с помощта на WhoCrashed. Помощната програма WhoCrashed Home е безплатна и представя драйвери, които са били натъпкани във вашия компютър с едно щракване. В повечето случаи може да идентифицира дефектен драйвер, който причинява страдания на вашия компютър. Това е краш дъмп на системния анализ, дъмпове на паметта и цялата събрана информация е представена тук в достъпна форма.

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

WhoCrashed разчита на пакета за отстраняване на грешки (програма windbg) от Microsoft. Ако този пакет не е инсталиран, WhoCrashed ще изтегли и автоматично ще извлече този пакет вместо вас. Просто стартирайте програмата и щракнете върху бутона Анализ. Когато имате инсталиран WhoCrashed на вашата система и ако тя се срине или затвори неочаквано, програмата ще ви уведоми дали изхвърлянето на сривове е активирано на вашия компютър и ще ви предложи предложения как да ги активирате.

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

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

Видове изхвърляния при срив на Windows

На примера на текущата операционна Windows системи 10 (Windows Server 2016) нека да разгледаме основните типове дъмпове на паметта, които системата може да създаде:

• Мини дъмп на паметта (малък дъмп на паметта)(256 KB). Този тип файл включва минимално количество информация. Той съдържа само BSOD съобщение за грешка, информация за драйверите, процесите, които са били активни по време на срива, и кой процес или нишка на ядрото е причинил срива.
• Дъмп на паметта на ядрото. Обикновено малък, една трета от обема на физическата памет. Дъмпът на паметта на ядрото е по-подробен от минидъмпа. Съдържа информация за драйвери и програми в режим на ядрото, включва разпределена памет Ядрото на Windowsи хардуерния абстракционен слой (HAL), както и паметта, разпределена за драйвери и други програми в режим на ядрото.
• Пълен дъмп на паметта. Най-големият по размер и изисква памет, равна на RAM на вашата система плюс 1MB, необходим Windowsза да създадете този файл.
• Автоматичен дъмп на паметта. Съответства на дъмп на паметта на ядрото по отношение на информацията. Различава се само в това колко място използва за създаване на дъмп файла. Този тип файл не съществува в Windows 7. Беше добавен в Windows 8.
• Дъмп на активната памет. Този тип филтрира елементи, които не могат да определят причината за повреда на системата. Това е добавено към Windows 10 и е особено полезно, ако използвате виртуална машина, или ако вашата система е Hyper-V хост.

Как да активирам генерирането на дъмп на паметта в Windows?

Използвайки Win + Pause, отворете прозореца на системните настройки, изберете " Допълнителни системни настройки" (Разширени настройки на системата). В раздела " Допълнително" (Разширени), раздел "" (Стартиране и възстановяване), щракнете върху бутона " Настроики" (Настройки). В прозореца, който се отваря, конфигурирайте действията в случай на повреда на системата. Поставете отметка в квадратчето " Записване на събития в системния журнал» (Запишете събитие в системния журнал), изберете типа дъмп, който да се генерира, когато системата се срине. Ако в квадратчето за отметка " Заменете съществуващия дъмп файл» (Презаписване на всеки съществуващ файл) поставете отметка в квадратчето, файлът ще бъде презаписан при всеки срив. По-добре е да премахнете отметката от това поле, тогава ще имате повече информация за анализ. Деактивирайте и автоматичното рестартиране на системата (Автоматично рестартиране).

В повечето случаи малък дъмп на паметта ще бъде достатъчен, за да се анализира причината за BSOD.

Сега, ако възникне BSOD, можете да анализирате дъмп файла и да намерите причината за грешките. Minidump се съхранява по подразбиране в папката %systemroot%\minidump. За да анализирате дъмп файла, препоръчвам да използвате програмата WinDBG(Microsoft Kernel Debugger).

Инсталиране на WinDBG на Windows

полезност WinDBGвключен в " Windows 10 SDK» (Windows 10 SDK). .

Файлът се извиква winsdksetup.exe, размер 1.3 MB.

Стартирайте инсталацията и изберете дали да инсталирате пакета на този компютър или да го изтеглите за инсталиране на други компютри. Инсталирайте пакета на локалния компютър.

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

Веднъж инсталирани, преките пътища на WinDBG могат да бъдат намерени в стартовото меню.

Настройка на свързването на .dmp файлове с WinDBG

За да отворите дъмп файлове с едно просто щракване, свържете разширението .dmp към помощната програма WinDBG.

1. Отворете командна линиякато администратор и изпълнявайте команди за 64-битова система: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
   windbg.exe –IA
   за 32-битова система:
   C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
   windbg.exe –IA
2. В резултат типове файлове: .DMP, .HDMP, .MDMP, .KDMP, .WEW ще бъдат съпоставени към WinDBG.

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

Символите за отстраняване на грешки (символи за отстраняване на грешки или файлове със символи) са блокове от данни, генерирани в процеса на компилиране на програма заедно с изпълним файл. Такива блокове данни съдържат информация за имена на променливи, извиквани функции, библиотеки и др. Тези данни не са необходими при стартиране на програмата, но са полезни при нейното отстраняване на грешки. Компонентите на Microsoft се компилират със символи, разпространявани чрез Microsoft Symbol Server.

Настройте WinDBG да използва Microsoft Symbol Server:

• Отворете WinDBG;
• Отидете в менюто Файл –> Път на символен файл;
• Напишете низ, съдържащ URL адреса за изтегляне на символи за отстраняване на грешки от уебсайта на Microsoft и папката за запазване на кеша: SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols В примера кешът е изтеглен към папката E:\Sym_WinDBG, можете да посочите всеки.
• Не забравяйте да запазите промените в менюто Файл–>Запазване на работното пространство;

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

SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:\Symbols

Ако няма интернет връзка, първо изтеглете пакета със символи от ресурса Windows Symbol Packages.

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

Дебъгерът WinDBG отваря дъмп файла и зарежда необходимите символи за отстраняване на грешки локална папкаили от интернет. По време на този процес не можете да използвате WinDBG. В долната част на прозореца (в командния ред на дебъгера) се появява надписът Debugee не е свързан.

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

Най-важното нещо, на което трябва да обърнете внимание, е кодът на грешката, който винаги е посочен в шестнадесетична стойност и изглежда така 0xXXXXXXXXX(посочено в една от опциите - СТОП:, 02.07.2019 0008F, 0x8F). В нашия пример кодът за грешка е 0x139.

Дебъгерът ви подканва да изпълните командата!analize -v, просто задръжте курсора на мишката върху връзката и щракнете. За какво е тази команда?

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

Основните точки, на които трябва да обърнете внимание, когато анализирате след изпълнение на командата !analyze -v (списъкът не е пълен).

1: kd> !analyze -v

* *
*Анализ за проверка на грешки*
* *
*****************************************************************************
Символно име на STOP грешката (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Описание на грешката (компонент на ядрото е повредил критична структура от данни. Тази повреда може потенциално да позволи на атакуващ да поеме контрола над тази машина):

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

Аргументи:
Arg1: 0000000000000003, LIST_ENTRY е повреден (т.е. двойно премахване).
Arg2: ffffd0003a20d5d0, Адрес на рамката за прихващане за изключението, което е причинило проверката за грешка
Arg3: ffffd0003a20d528, Адрес на записа на изключение за изключението, което е причинило проверката за грешка
Arg4: 0000000000000000, Запазено
Подробности за отстраняване на грешки:
------------------

Броячът показва колко пъти системата се срива с подобна грешка:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

STOP код на грешка в съкратен формат:

BUGCHECK_STR: 0x139

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

ПРОЦЕС_ИМЕ: sqlservr.exe

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

ERROR_CODE: (NTSTATUS) 0xc0000409 - Системата откри препълване на базиран на стека буфер в това приложение. Това превишаване може потенциално да позволи на злонамерен потребител да получи контрол над това приложение.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - Системата откри препълване на базиран на стек буфер в това приложение. Това превишаване може потенциално да позволи на злонамерен потребител да получи контрол над това приложение.

Последно повикване в стека:

LAST_CONTROL_TRANSFER: от fffff8040117d6a9 до fffff8040116b0a0

Стек от повиквания по време на повреда:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528: nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiFastFailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9: nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951: nt! ?? ::FNODOBFM::`низ"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380: nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiSystemServiceCopyEnd+0x13
000000ee'f25ed2b8 00000000'00000000: 00000000'00000000 00000000'00000000 00000000'00000000

Частта от кода, където е възникнала грешката:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr ,0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: Собственик на машина

Името на модула в таблицата с обекти на ядрото. Ако анализаторът е успял да открие проблемен драйвер, името се показва в полетата MODULE_NAME и IMAGE_NAME:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

1: kd > lmvm nt
Преглед на пълния списък с модули
Зареден файл със символно изображение: ntkrnlmp.exe
Картографиран файл с изображение на паметта: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Път на изображението: ntkrnlmp.exe
Име на изображението: ntkrnlmp.exe
Вътрешно име: ntkrnlmp.exe
Оригинално име на файл: ntkrnlmp.exe
Версия на продукта: 6.3.9600.18946
Версия на файла: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

В горния пример анализът посочи файла на ядрото ntkrnlmp.exe. Когато анализът на дъмпа на паметта показва системен драйвер(например win32k.sys) или файл на ядрото (както в нашия пример ntkrnlmp.exe), най-вероятно даден файлне е причината за проблема. Много често се оказва, че проблемът е в драйвера на устройството, BIOS настройкиили неизправност на оборудването.

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

Например:

Път на изображението: \SystemRoot\system32\drivers\cmudaxp.sys
Име на изображението: cmudaxp.sys

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