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

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

За да диагностицирате правилно проблем, първо трябва да анализирате специален файлсистема, наречена minidump (изхвърляне на паметта). Създаването на такива файлове води до срив в системата, освен това те могат да ни информират какво точно е довело до срива.

1. За да активирате такъв автоматичен запис на малък дъмп на паметта (деактивиран по подразбиране), отидете в свойствата на компютъра и отидете на раздела " Допълнителни опциисистеми" (това включване се предоставя за всички системи, не само за Windows 10):

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

Два начина за декриптиране на малък памет на паметта

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

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

За втори методтрябва да инсталирате инструменти за отстраняване на грешки за Windows и също така да изтеглите помощната програма bsdos_utility. Освен това, след като разопаковате скрипта bsdos_utility.cmd, трябва да го преместите в устройството C:\ (можете да създадете отделна папка, но не забравяйте, че адресният низ за стартиране на скрипта ще се различава от нашия пример). След това в командния ред напишете:

C:\bsdos_utility.cmd

След показване на списъка с всички дъмпове от списъка C:\Windows\Minidump\, след което скриптът ще попита кой дъмп трябва да бъде анализиран. Можете също така сами да изберете желания минисметка, когато изпълнявате скрипта:

По този начин е възможно да се открие масата Windows грешки 10, което е причинило BSOD, както и проблемни .exe програми, които са причинили син екран.

На следващата стъпка за избор на компоненти за инсталиране ( Изберете функциите, които искате да инсталирате) маркирайте само това, от което се нуждаем - Инструменти за отстраняване на грешки за Windows и натиснете Инсталирай

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

След като инсталацията приключи, намираме в менюто „Старт“ или на началния екран в групата с преки пътища Комплекти за Windowsполезност windbgи го стартирайте с администраторски права

Ако по някаква причина прекият път не може да бъде намерен, тогава можете да стартирате изпълнимия файл от инсталационната директория - C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\windbg.exe

В главното меню на програмата windbgизберете елементи файл > Път на символен файл. В прозореца, който се отваря, вмъкнете ред, дефиниращ let към локалната директория на кеша на символите и неговия онлайн източник:

Запазваме настройките, като избираме елементите в главното меню файл > Запазване на работното пространство

Отворете файла с дъмп на паметта, като изберете от менюто файл > Отворете Crash Dump...

Изберете файл ПАМЕТ.DMP(намира се по подразбиране в директорията C:\Windows) и щракнете отворен

Ще се появи информация кой конкретен изпълним модул е ​​накарал системата да спре да работи. Като щракнете върху хипервръзка !analyze-vможете да получите по-подробна информация за състоянието на системата в момента на стоп грешката.

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

В този пример цялата информация за анализ на дъмпа ще бъде изхвърлена в четима форма във файла C:\Debuglog.txt

Източници на информация:

Добър ден, скъпи колеги и читатели на сайта на блога. Днес искам да ви кажа как да анализирате дъмп на паметта на Windows 10 Redstone. Това се прави в повечето случаи, когато получите син екран на смъртта с грешка, след което компютърът ви се рестартира. И този анализпомага да се разбере причината за повредата.

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

И така, какво е дъмп на паметта в операционната система Windows 10 Redstone. Описах ви по-горе обща каузапри което се появява дъмп на системната памет и това са сините екрани на смъртта. Причините за появата им са много обширни:

• Несъвместимост на приложението
• Несъвместимост на драйвера
• Нов актуализации на windows
• Устройството не е съвместимо

Това е само малък обобщен списък, тъй като има много кодове за грешки от сини екрани, ще дам най-новите.

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

Къде е конфигуриран crash dump на windows 10?

Като начало, нека разберем къде се прави настройката, която е отговорна за дъмпа на паметта при срив на Windows 10. Щракнете с десния бутон върху бутона за стартиране на Windows 10 и от контекстно менюизберете Система.

В системния прозорец, който се отваря, вие сте отляво горен ъгълизберете Разширени системни опции.

Това е мястото, където се конфигурира дъмпът на паметта на Windows 10. Щракнете върху елемента с настройки в Boot and Recovery.

От настройките, дъмп на паметта на Windows 10, искам да отбележа следното:

• Записване на събитие в syslog> тук информация за синия екран ще бъде добавена към регистрационните файлове операционна система.
• Бягай автоматично рестартиране> за да продължите след грешка
• Напишете информация за отстраняване на грешки > ви позволява да изберете типа на дъмп файла, повече за това по-долу.
• Заменете съществуващия дъмп файл, полезно квадратче за отметка, тъй като тези дъмпове могат да тежат десетки гигабайти, това е много критично за малки ssd устройства.

Видове дъмпове на паметта

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

• Малък дъмп на паметта 256 KB: Файловете с малък дъмп на паметта съдържат следната информация:

– съобщение за фатална грешка, неговите параметри и други данни;

– списък на заредените драйвери;

– контекст на процесора ( PRCB), на който е възникнал повредата;

EPROCESS) за процеса, причинил грешката;

– информация за процеса и контекст на ядрото ( РЕЗБА) за нишката, която е причинила грешката;

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

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

Минисметката се съхранява по пътя C:\Windows\Minidump

• Дъмп на паметта на ядрото > записва само паметта на ядрото. В зависимост от количеството физическа памет на компютъра в този случай, файлът за виртуална памет изисква от 50 до 800 MBили една трета от физическата памет на компютъра върху тома за зареждане.
• Full memory dump > е, всичко е ясно от името. Пише абсолютно всичко, това е максималната информация за синия екран, дава сто процента диагностика на проблема.

Намира се по пътя C:\Windows\Memory.dmp

• Дъмп на активна памет > активната памет на хост машината попада тук, това е функция повече за сървърни платформи, тъй като те могат да се използват за виртуализация и така че информацията за виртуалните машини да не попадне в дъмпа, тази опция е измислена.

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

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

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

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

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

Теоретично, статичността (неизменността) на "отпечатъка" на паметта се обяснява с факта, че когато се извика функцията 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 MB (тези 257 MB са разделени на някакъв вид заглавка + данни на драйвера). Всъщност в някои операционни системи долният праг на файла за виртуална памет може да бъде зададен точно на стойността на размера на физическата памет.

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

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

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

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Настроики:

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

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

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

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

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

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

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

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