По време на критична повреда операционната система Windows прекъсва и показва син екран на смъртта (BSOD). Съдържанието на RAM паметта и цялата информация за възникналата грешка се записват във файла на страницата. При следващото зареждане на Windows се създава срив на срив с информация за отстраняване на грешки въз основа на записаните данни. Създава се критичен запис за грешка в системния регистър на събитията.
внимание! Авариен дамп не се създава, ако дисковата подсистема се повреди или възникне критична грешка по време на началния етап на зареждане на Windows.Съдържание:
- Видове Windows Crash Dumps
- Как да активирате създаването на сметище в Windows?
- Инсталиране на WinDBG на Windows
- Конфигуриране на свързването на .dmp файлове с WinDBG
- Конфигуриране на сървъра за символи за отстраняване на грешки в WinDBG
- Анализ на срив на срив в WinDBG
Видове Windows Crash Dumps
Използвайки настоящата операционна система Windows 10 (Windows Server 2016) като пример, помислете за основните типове изхвърляне на памет, които една система може да създаде:
- Мини сметище за памет (256 KB) Този тип файлове включва минимално количество информация. Той съдържа само съобщението за грешка в BSOD, информация за драйверите, процесите, които са били активни в момента на срива и кой процес или нишка на ядрото е причинил срива..
- Изхвърляне на паметта на ядрото. Като правило, малки по размер - една трета от физическата памет. Изхвърлянето на паметта на ядрото е по-многословно от мини. Тя съдържа информация за драйвери и програми в режим на ядрото, включва памет, разпределена на слоя за абстракция на ядрото на Windows и хардуер (HAL), както и памет, разпределена на драйвери и други програми в режим на ядрото..
- Пълно изхвърляне на паметта. Най-големият по обем и изисква памет, равна на RAM на вашата система плюс 1MB, което е необходимо за Windows да създаде този файл.
- Автоматично изхвърляне на паметта. Съответства на ядрото на основната памет по отношение на информацията. Тя се различава само в това колко пространство използва за създаване на dump файла. Този тип файл не съществува в Windows 7. Добавен е в Windows 8..
- Активно изхвърляне на паметта. Този тип филтрира елементи, които не могат да определят причината за повреда в системата. Това беше добавено в Windows 10 и е особено полезно, ако използвате виртуална машина или ако вашата система е хост на Hyper-V..
Как да активирате създаването на сметище в Windows?
Използвайте Win + Pause, отворете прозорец със системни параметри, изберете „Допълнителни системни параметри"(Разширени системни настройки). В раздела"допълнително"(Разширено), раздел"Изтеглете и възстановете"(Стартиране и възстановяване) щракнете върху"параметри"(Настройки). В прозореца, който се отваря, конфигурирайте действието в случай на повреда на системата. Поставете отметка в квадратчето"Запишете събития в системния дневник"(Напишете събитие в системния дневник), изберете типа сметище, което трябва да бъде създадено, когато системата се срине. Ако е в квадратчето"Заменете съществуващия Dump файл"(Презапишете всеки съществуващ файл) квадратчето, файлът ще се презаписва всеки път, когато се срине. По-добре е да премахнете отметката от това поле, след което ще имате повече информация за анализ. Деактивирайте също автоматичното рестартиране на системата (Автоматично рестартиране).
В повечето случаи, малко сметище за памет ще бъде достатъчно, за да анализирате причината за BSOD..
Сега, когато се появи BSOD, можете да анализирате dump файла и да намерите причината за неуспеха. Мини-бутонът по подразбиране се запазва в папката% systemroot% \ minidump. За да анализирате dump файла, препоръчвам да използвате програмата WinDbg (Отладчик на Microsoft Kernel).
Инсталиране на WinDBG на Windows
полезност WinDbg включени в „SDK за Windows 10"(Windows 10 SDK). Изтеглете тук..
Файлът се извиква winsdksetup.exe, размер 1.3 MB.
WinDBG за Windows7 и по-ранни системи е включен в пакета „Microsoft Windows SDK за Windows 7 и .NET Framework 4“. Изтеглете тук.Стартирайте инсталацията и изберете какво трябва да се направи - инсталирайте пакета на този компютър или го изтеглете за инсталиране на други компютри. Инсталирайте пакета на локалния компютър.
Можете да инсталирате целия пакет, но за да инсталирате само инструмента за отстраняване на грешки, изберете Инструменти за отстраняване на грешки за Windows.
След инсталирането, WinDBG преки пътища могат да бъдат намерени в стартовото меню.
Конфигуриране на свързването на .dmp файлове с WinDBG
За да отворите dump файлове с обикновено щракване, свържете .dmp разширението с помощната програма WinDBG.
- Отворете командния ред като администратор и стартирайте командите за 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 - В резултат типовете файлове: .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, можете да зададете всяка. - Не забравяйте да запазите промените в менюто. досие -> Запазете WorkSpace;
WinDBG ще търси символи в локалната папка и ако не намери необходимите символи в нея, ще изтегли героите от посочения сайт самостоятелно. Ако искате да добавите собствена папка със символи, тогава можете да я направите така:
SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbols; c: \ Symbols
Ако няма връзка с Интернет, първо изтеглете пакета символи от ресурса на Windows Symbol Packages..
Анализ на срив на срив в WinDBG
Отладникът на WinDBG отваря дампъл файл и изтегля необходимите символи за отстраняване на грешки от локална папка или от Интернет. Не можете да използвате WinDBG по време на този процес. В долната част на прозореца (в командния ред за отстраняване на грешки) се появява Debugee не е свързан.
Командите се въвеждат в командния ред, разположен в долната част на прозореца.
Най-важното, на което трябва да се обърне внимание, е кодът за грешка, който винаги е посочен в шестнадесетична стойност и има формата 0xXXXXXXXX (посочено в една от опциите - STOP: 0x0000007B, 02.02.2019 0008F, 0x8F). В нашия пример код за грешка 0x139.
Пълното ръководство за грешки можете да намерите тук..Отладникът предлага да стартирате командата! Анализирайте -v, просто задръжте курсора на мишката над връзката и щракнете. За какво е тази команда??
- Той извършва предварителен анализ на сметището и предоставя подробна информация, за да започне анализ..
- Тази команда показва кода за спиране и символичното име на грешката..
- Той показва стек от командни обаждания, довел до срив..
- Освен това тук се показват неизправности в IP адреса, процеса и регистрацията..
- Екипът може да даде готови препоръки за решаване на проблема..
Основните моменти, на които трябва да обърнете внимание, когато анализирате след изпълнение на командата! Analyze -v (списъкът е непълен).
1: kd> !анализира -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
Процесът, по време на изпълнението на който е възникнал отказът (не е задължително причината за грешката, точно в момента на повредата в паметта е извършен този процес):
PROCESS_NAME: sqlservr.exe
CURRENT_IRQL: 2
Дешифриране на кода за грешка: В това приложение системата открива препълване на буфер от стекове, което може да позволи на атакуващия да получи контрол над това приложение.
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'0000000000000000'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 :: 'string' + 0x17252
ffffd000'3a20d8c0 fffff804'013a34ac: 00000000'00000004 00000000'00000000 ffffd000'3a20d9d8 ffffe001'0a34c600: nt! IopSynchronousServiceTail + 0x379
ffffd000'3a20d990 fffff804'0117d313: ffffffff'fffffffe 00000000'00000000 00000000'00000000000000eb'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 00000000'00000000: 0x00007ffb'475307da
Частта от кода, в която е възникнала грешката:
FOLLOWUP_IP:
nt! KiFastFailDispatch + d0
fffff804'0117da50 c644242000 mov byte ptr [rsp + 20h], 0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt! KiFastFailDispatch + d0
FOLLOWUP_NAME: MachineOwner
Името на модула в таблицата с обекти на ядрото. Ако анализаторът успя да открие проблемен драйвер, името се показва в полетата MODULE_NAME и IMAGE_NAME:
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
Ако щракнете върху връзката на модула (nt), ще видите подробна информация за пътя и други свойства на модула. Намерете посочения файл и изучете неговите свойства.
1: kd> lmvm ntПрегледайте пълния списък с модули
Зареден файл с изображение на символа: ntkrnlmp.exe
Картографиран файл с памет: C: \ ProgramData \ dbg \ sym \ ntoskrnl.exe \ 5A9A2147787000 \ ntoskrnl.exe
Пътят на изображението: ntkrnlmp.exe
Име на изображението: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)
В горния пример анализът насочи към файла ядро ntkrnlmp.exe. Когато анализът на изхвърлянето на паметта сочи към системния драйвер (например win32k.sys) или файл с ядро (както в нашия пример ntkrnlmp.exe), най-вероятно този файл не е причината за проблема. Често се оказва, че проблемът се крие в драйвера на устройството, настройките на BIOS или хардуерната повреда.
Ако видяхте, че BSOD се дължи на драйвер на трета страна, името му ще бъде посочено в стойностите MODULE_NAME и IMAGE_NAME.
Например:
Пътят на изображението: \ SystemRoot \ system32 \ драйвери \ cmudaxp.sys
Име на изображението: cmudaxp.sys
Отворете свойствата на драйверния файл и проверете неговата версия. В повечето случаи проблемът с драйверите се решава чрез актуализирането им..
