Комплетан водич за анализу BSOD-ова и избацивања кернела у оперативном систему Windows

Информатек Дигитал » Средства » Комплетан водич за анализу BSOD-ова и избацивања кернела у оперативном систему Windows

Када се Windows рачунар замрзне са плавим екраном, то није само досадно: у меморијском дампу се често крију вредне информације које нам говоре шта се тачно догодило у језгру. Уместо да кривите RAM меморију, BIOS или одмах поново форматирате, вреди научити како да читате те податке.

Уз мало вежбе, алати попут WinDbg и функције попут !analyze -v, .bugcheck или исправна употреба симбола нам омогућавају да пређемо са „Добијам грешку плавог екрана“ на „Знам који драјвер, ресурс или уређај је изазвао BSOD“. У овом чланку ћемо корак по корак и детаљно објаснити како анализирати BSOD користећи његов дамп језгра, које врсте дампова постоје, како све припремити и које команде користити да би се из анализе извукло максимум.

Шта је БСОД и које информације садржи?

Када Windows наиђе на стање које угрожава интегритет система и не може се безбедно опоравити, он упућује интерни позив кернелу под називом KeBugCheckEx . Овај позив је оно што покреће озлоглашени Плави екран смрти (BSOD).

KeBugCheckEx увек прима пет аргумената: STOP код (код за проверу грешке) и четири додатна параметра који пружају технички контекст грешке. Те исте податке затим можемо да консултујемо.

• На плавом екрану класично, ако систем није конфигурисан да се аутоматски поново покреће.
• У дневнику догађаја система Windows, у оквиру Прегледача догађаја (системски дневник).
• У датотеци са подацима о меморији (мини-дамп, дамп језгра или пун дамп), користећи WinDbg и команде попут !analyze -v o .bugcheck.

Сваки код за проверу грешака има симболичко име и придружену хексадецималну вредност . На пример, код за проверу грешака DRIVER_POWER_STATE_FAILURE има код 0x9F , док RESOURCE_NOT_OWNED одговара 0xE3 . Ови кодови и њихови параметри су документовани у Мајкрософтовом референци за кодове за проверу грешака, коју би увек требало да држите при руци.

Поред кода, плави екран може приказати име потенцијално укљученог .sys драјвера . Ако је у питању драјвер треће стране (антивирус, мрежна картица, графичка картица итд.), често имамо јасног сумњивца. Ако се појави генеричка системска компонента (ntoskrnl.exe, win32k.sys итд.) или ако се уопште ништа не појави, мораћемо да извршимо дамп меморије и користимо WinDbg да бисмо даље истражили.

Врсте меморијских дампова у оперативном систему Windows

Да бисмо детаљно анализирали BSOD, потребно је да Windows генерише датотеку са подацима о меморији (DMP) када дође до грешке. Ова датотека бележи стање система у тренутку грешке и може бити различитих типова.

У опцијама „Покретање и опоравак“ (десни клик на „Овај рачунар / Мој рачунар“ → Својства → Напредна подешавања система → картица „Напредно“ → дугме „Подешавања“ испод „Покретање и опоравак“), можете бирати између неколико врста дампова. Свака има своје предности и мане.

Мали дамп меморије (Minidump)

Формат мини-дампа је најмањи (око 64 KB) и такође најограниченији за напредно отклањање грешака. Међутим, остаје користан за добијање брзе дијагнозе у многим сценаријима BSOD-а.

Мини-дамп складишти, између осталих података:

• Порука о заустављању, код за проверу грешака и његови параметри.
• Контекст процесора (PRCB) процесора који је изазвао квар.
• Информације о процесу језгра (EPROSS) активног процеса у тренутку пада система.
• Информације о нитима у језгру (ETHREAD) нити која је изазвала пад система.
• Стек позива у режиму језгра за ту тему (до 16 KB).
• Листа учитаних драјвера у време доношења пресуде.
• Листа учитаних и преузетих модула.
• Блок података за отклањање грешака са основним системским информацијама.

Ова врста дампа се обично чува у %SystemRoot%\Minidump (на пример, C:\Windows\Minidump ). За многе основне случајеве подршке или дијагностике, мини-дамп темељно анализиран помоћу !analyze -v може бити више него довољан.

Думп меморије кернела

Дамп меморије језгра садржи садржај меморије језгра у тренутку пада система, искључујући меморијске просторе корисничких процеса. Нуди драгоцену равнотежу између величине и детаља и често је препоручена опција за дијагностиковање већине BSOD-ова.

Овај дамп се чува као MEMORY.DMP у %SystemRoot% (подразумевано, C:\Windows\MEMORY.DMP ). Његова величина зависи од меморије коју користи језгро, али је обично много већи од мини-дампа и много лакши за управљање од потпуног дампа.

Комплетно избацивање меморије

Потпуни дамп меморије чува практично сав садржај RAM меморије у тренутку грешке: језгро, корисничке процесе итд. То је најдетаљнији, али и онај који заузима највише простора и најзахтевнији је у погледу конфигурације.

Да би комплетан дамп био валидан, мора бити испуњено неколико услова:

• El датотека за позивање мора бити у иста партиција на којој је инсталиран Windows.
• Мора да постоји простор на диску најмање једнак величини физичке меморије машине.
• Не премештајте датотеку странице на други физички диск ако желите да избегнете оштећене дампове.

У производним окружењима са пуно RAM меморије, потпуни дамп може бити непрактичан, али за веома сложене или повремене случајеве може направити велику разлику у лоцирању проблема.

Конфигуришите Windows да снима и евидентира BSOD-ове

Пре него што се почне са радом са WinDbg-ом, неопходно је осигурати да систем исправно генерише дампове и евидентира догађај плавог екрана.

У прозору „Покретање и опоравак“ налазимо неколико релевантних опција:

• Запишите догађај у системски дневник: мора бити омогућено да би се провера грешака забележила у Прегледнику догађаја.
• Запишите информације о отклањању грешака: овде бирамо Minidump, Kernel memory dump или Complete memory dump.
• путања датотеке за извод: подразумевано %СистемРоот%\МЕМОРИ.ДМП за језгро/пуну верзију.
• Поново покрените аутоматскипрепоручљиво је да то уклонимо из поља ако желимо мирно гледајте плави екран и обратите пажњу на оно што се појављује.

Код неких произвођача или одељења за подршку, као што је случај са одређеним мрежним адаптерима, од корисника се тражи да пошаље дамп датотеку . Обично се налази у C:\Windows\memory.dmp и препоручује се да је пронађете по датуму/времену како бисте идентификовали датум који одговара последњем квару.

Ако желимо да будемо у могућности да извршимо избацивање података чак и када је систем замрзнут (без реакције тастатуре или миша), постоји и веома користан трик за PS/2 тастатуре (не USB/Bluetooth), који се састоји у конфигурисању регистра да покрене избацивање података комбинацијом тастера.

Присилно избаците дамп помоћу тастатуре у случају замрзавања

Да бисте генерисали дамп меморије чак и ако је екран потпуно замрзнут, можете користити опцију CrashOnCtrlScroll на PS/2 тастатурама. Ова метода не важи за USB или Bluetooth тастатуре.

У регистру морамо креирати или изменити следећи кључ:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Након поновног покретања, у било ком тренутку (чак и са замрзнутим екраном) можете покренути контролисано пад система и натерати систем да генерише извод меморије притиском на десни тастер CTRL , а затим два пута тастер Scroll Lock . Ово је веома корисно за истраживање тешких падова система који сами по себи не приказују BSOD.

Увод у WinDbg за анализу дампова језгра

WinDbg је водећи Мајкрософтов алат за отклањање грешака у језгру и анализу дампа меморије . Доступан је бесплатно (тренутно и у Мајкрософт продавници као WinDbg Preview) и, иако на први поглед може деловати застрашујуће, за почетну анализу BSOD-а потребно је да разумете само неколико основних опција.

Можемо инсталирати WinDbg на сам погођени рачунар или на било који други рачунар ; .dmp датотека се може копирати преко мреже, путем USB-а или чак компресовати у CAB датотеку. Процесор и верзија Windows-а на којој анализирамо дамп не морају нужно да се подударају са онима на рачунару који се срушио.

Покрените WinDbg са дампом из командне линије

Класичан начин за отварање дампа меморије у WinDbg-у је коришћење командне линије са параметром `-z` , који наводи путању до датотеке дампа. Ово се може комбиновати са другим параметрима као што су симбол или бинарна путања.

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Модификатор -v активира детаљан режим , што је веома корисно за преглед више контекста. Поред WinDbg-а, постоји и kd.exe , дебагер базиран на конзоли који вам омогућава да урадите практично исту ствар, али без графичког интерфејса.

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Отворите дамп из графичког интерфејса

Ако је WinDbg већ отворен у пасивном режиму, можете учитати датотеку са информацијама о паду система користећи мени Датотека → Отвори дамп о паду система или пречицу Ctrl+D . Изаберите .dmp датотеку (или чак .cab датотеку која је садржи) и WinDbg ће учитати информације о паду система.

Друга алтернатива је покретање WinDbg-а, и када сте унутра, покрените команду .opendump наводећи путању до датотеке са дамповима, а затим команду g (Go) да бисте покренули сесију отклањања грешака у дамповима:

.opendump C:\Windows\Memory.dmp
g

WinDbg чак дозвољава очистите више депонија одједномдодавање неколико параметара -z у командној линији или понављањем .opendump са различитим рутама и управљање сесијом са више одредишта.

Конфигуришите путању симбола у WinDbg-у

Без симбола, WinDbg ради готово слепо. Симболи (.pdb) садрже информације о дебаговању функција, интерних структура, променљивих, померања итд. и неопходни су за поуздану анализу, посебно при раду са кернелом.

Да бисте користили јавне симболе компаније Microsoft без потребе за ручним преузимањем, најбоља пракса је да конфигуришете сервер симбола који показује на званични Microsoft сервер и локални директоријум кеша. На пример, прво можемо да креирамо фасциклу C:\symbols , а затим, у WinDbg-у, конфигуришемо путању симбола на следећи начин:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

Ово се може урадити из менија Датотека → Путања датотеке симбола или, у прегледу WinDbg-а, из Датотека → Подешавања → Подешавања отклањања грешака подешавањем „Подразумеване путање симбола“. Први пут када анализирате дамп са одређеног система, програм за отклањање грешака ће аутоматски преузети потребне симболе са интернета, што може потрајати неколико минута у зависности од ваше везе.

Важно је напоменути да јавни симболи компаније Microsoft понекад не укључују све интерне информације о типу и да можете видети упозорења попут „Ваш дебагер не користи исправне симболе“ или референце на нерешиве типове. За основну анализу BSOD-а, јавни симболи су обично довољни, али ако вам је потребно више детаља, постојаће ограничења.

Прва анализа: основне команде и провера грешака

Када се дамп учита и симболи конфигуришу, WinDbg обично приказује заглавље са системским информацијама и упозорењем као што је „Користите !analyze -v да бисте добили детаљне информације о отклањању грешака“. То је наша прва станица за почетну анализу.

Команда !analyze -v врши аутоматску анализу дампа и обично пружа:

• Код за проверу грешака (на пример, 0xE3, 0xD1, 0x9F, 0x44…).
• Параметри Arg1, Arg2, Arg3 и Arg4 из провере грешака.
• Највероватнији модул или драјвер узрок неуспеха (Probably caused by).
• Повезани процес у том тренутку (на пример, Teams.exe).
• Стек позива (траг стека) нити која је изазвала пад.
• Информације о корпи и хешеве грешака, корисне за корелацију поновљених грешака.

На пример, у случају провере грешака из стварног света RESOURCE_NOT_OWNED (0xE3) , анализа може указати на то да је нит покушала да ослободи ресурс који не поседује , приказујући Teams.exe као процес и указујући на win32kbase.sys у функцији као што је DrvEnumDisplaySettings . Ово сугерише да је нит која је довела до неуспеха упитовала или манипулисала подешавањима приказа из корисничког простора кроз графички слој Windows-а.

Да бисмо мало дубље заронили у детаље стоп кода и његових параметара, имамо и команду .провера грешакашто поново приказује проверу грешака и четири аргумента, што је корисно ако желимо да поновимо те информације без поновног покретања свега. !analyze -v.

Практични случајеви: покретачи и типични конфликти

Анализа BSOD-а се обично врти око идентификовања неисправних или неисправних драјвера , сукоба драјвера, неправилног приступа меморији, неправилног руковања IRP-овима (I/O Request Packets) и тако даље. Погледајмо неке практичне примере из стварног света како бисмо боље разумели процес.

RESOURCE_NOT_OWNED (0xE3) повезано са Teams и win32kbase.sys

У сценарију оперативног система Windows 10 где се, након неколико дана непрекидног рада, појављује BSOD са грешком bugcheck 0xE3 (RESOURCE_NOT_OWNED) , мини-кернел дамп приказује нешто слично:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

Овде, дебагер показује да је проверу грешака покренула нит повезана са Teams.exe , али код који се заправо налази на стеку у критичном тренутку припада win32kbase.sys , тачније функцији DrvEnumDisplaySettings . Ово не значи нужно да је Teams директан кривац, већ да Teams позива кориснички API што резултира грешком у синхронизацији или ослобађању ресурса у графичком подсистему.

Код оваквих дијагноза, закључак је често да је у питању грешка у графичком стеку Windows-а, одређени видео драјвер или интеракција између апликације и драјвера. Стварно решење може укључивати ажурирање драјвера за GPU, ажурирање Teams-а или чак примену одређених Windows закрпа , уместо једноставног чекања да се проблем сам поправи.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) са NotMyFault

Услужни програм NotMyFault компаније Sysinternals је образовни алат који вам омогућава да генеришете грешке језгра на контролисан начин како бисте научили како да анализирате снимке екрана. На пример, ако покренете опцију High IRQL fault (кернел режим) из NotMyFault- а и кликнете на „Do Bug“, изазваћете грешку DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

На плавом екрану видећемо нешто попут DRIVER_IRQL_NOT_LESS_OR_EQUAL и могуће кандидат за драјвер (на пример, MyFault.sys , драјвер који користи алат). Када се дамп генерише и отвори помоћу WinDbg-а, почетни излаз може изгледати отприлике овако:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Иако дебагер указује на оштећење меморије , знамо да је прави узрок повезан са NotMyFault и његовим драјвером. Да бисмо то потврдили, можемо наставити са праћењем помоћу команди као што је !thread да бисмо видели које позиве нит прави у тренутку квара и !irp да бисмо анализирали укључени IRP ако је провера грешака повезана са I/O операцијама.

На пример, помоћу `!thread <dir_thread>` можемо видети траг стека нити и лоцирати инструкцију где се појављује `myfault+0x403` , што указује на то где је тест драјвер погрешио. Одатле можемо испитати IRP, статус меморије и тако даље, баш као што бисмо то урадили са правом грешком.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) и USB конфликти

Још један веома илустративан случај је провера грешака (bugcheck). ВИШЕ_ЗАТВРШЕНИ_ЗАХТЕВИ_ПРЕТХОДА_ПРЕТХОДА_ПРЕТХОДА (0x44)Ова грешка се јавља када IRP (I/O Request Packet) је завршен више пута, обично зато што два различита драјвера верују да поседују исти IRP и оба позивају IoCompleteRequest().

Анализа са !analyze -v може дати опис сличан овом:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

У почетку, осумњичени изгледа као usbehci.sys , Мајкрософтов драјвер за USB EHCI контролере. Међутим, релативно је ретко да грешку заправо изазове изворни Windows драјвер без интеракције са трећом страном. Да бисмо дошли до поенте, користимо IRP адресу коју је обезбедила грешка (Arg1) и покрећемо !irp <IRP_ADDRESS> :

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

У последњем реду јасно видимо стринг \Driver\usbehci ax88172 , што открива да је IRP прошао и кроз usbehci.sys и кроз драјвер под називом ax88172.sys , повезан са одређеним USB мрежним чипсетом (AX88172). Стога можемо закључити да конфликт потиче од овог USB NIC драјвера треће стране , а не од генеричког EHCI драјвера компаније Microsoft.

У том случају, решење укључује ажурирање драјвера USB адаптера, замену уређаја или, ако је потребно, његово уклањање . Ова врста IRP анализе је посебно корисна за BSOD-ове везане за USB, складиштење података, мрежне картице и, генерално, било коју компоненту која користи интензиван I/O.

Корисне WinDbg команде у режиму језгра

Поред !analyze -v и .bugcheck , постоји неколико WinDbg екстензија и команди које су веома корисне када желимо да се мало дубље позабавимо израдом дампа језгра.

Неки од најчешћих су:

• !нит: Приказује детаљне информације о нити, укључујући њен стек позива, стање, повезане IRP-ове итд. Омогућава вам да видите „последње акције“ нити која је била покренута када се систем срушио.
• !процес 0 0Ово наводи све активне процесе у време пада система. Корисно је за идентификацију да ли су на машини били покренути сумњиви процеси, сервиси, EDR, антивирус итд.
• !irpанализира одређени IRP и приказује траг возача кроз које је прошаоУ/И команда, заставице итд. су кључне код грешака повезаних са МУЛТИПЛЕ_ИРП_ЦОМПЛЕТЕ_РЕКУЕСТС и друге У/И грешке.
• !cpuinfo: пружа информације о процесору (произвођач, MHz, потписи, карактеристике), корисно за проверу хардверских окружења.
• !peb: приказује детаље PEB-а (блока процесног окружења), као што су име рачунара, путања инсталације Windows-а, број процесора итд.
• !токен: пружа информације о безбедносним токенима, дозволама и безбедносном контексту процеса или нити.
• .cls: брише командни прозор, као у обичној конзоли.

Поред тога, многе специфичне екстензије фајл система (нпр. за PnP, NTFS, итд.) вам омогућавају да извучете још више информација из дампова. У неким случајевима, WinDbg ће назначити присуство BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), што су додатни блокови података снимљени током провере грешака ради олакшавања дијагнозе одређених системских области.

Коришћење верификатора драјвера за проналажење проблематичних драјвера

Веома висок проценат грешака „Плави екран смрти“ (BSOD) у оперативном систему Windows узрокован је неисправним или лоше програмираним драјверима . Да би проактивно открио ове врсте проблема, систем укључује моћан алат: Верификатор драјвера.

Верификатор драјвера ради у реалном времену и подвргава одабране драјвере низу тестова и тестова оптерећења: проверава исправну употребу меморије, коришћење базе језгра, IRQL, IRP итд. Ако открије да драјвер не ради исправно, може изазвати контролисани BSOD како бисмо могли да анализирамо много јаснији дамп, где се кривац обично лако идентификује.

Да бисте покренули менаџер за проверу драјвера, једноставно отворите командну линију са администраторским привилегијама и откуцајте:

verifier

Одатле можемо да изаберемо које драјвере желимо да проверимо. Мудро је бити опрезан: Верификатор додаје оптерећење систему и може да смањи перформансе , па се препоручује да се верификација омогући само за што мањи број сумњивих драјвера уместо да се све бира насумично.

Када Верификатор покрене BSOD након откривања неисправног понашања, можемо анализирати дамп језгра помоћу WinDbg-а и, надамо се, јасно видети који је драјвер забележен и шта је погрешно урадио. Мајкрософтови референтни чланци о Верификатору драјвера детаљно објашњавају различите опције и стратегије коришћења.

Практични савети за инжењере и техничаре

Без обзира да ли сте програмер драјвера, програмер софтвера који комуницира са кернелом или једноставно техничар коме се јављају сви плави екрани смрти, постоје неке смернице које вреди усвојити како бисте избегли да се изгубите у џунгли плавих екрана смрти.

Први корак, када је грешка повезана са вашим сопственим кодом, јесте систематско коришћење дебагера језгра да би се репродуковао и анализирао проблем . Повезивањем дебагера са циљном машином (преко мреже, серијског порта итд.), провера грешака ће проузроковати да се систем заустави унутар дебагера уместо да директно прикаже плави екран. Одатле можете прегледати меморију, стекове, структуре и исправити код.

У другим сценаријима, провере грешака могу бити узроковане драјверима, хардвером или софтвером трећих страна које не контролишемо. У тим случајевима, циљ се помера са „поправљања кода“ на изоловање и ублажавање проблема.

• Идентификујте сумњиви драјвер или хардверску компоненту користећи WinDbg и анализу дампа.
• Ажурирај или врати верзије драјвера, BIOS-а, фирмвера или повезаних апликација.
• Уклоните или замените USB уређаји, графичке картице, мрежни адаптери конфликтан.
• Да се ​​ослоним на Прегледач догађаја, Sysinternals, алати за праћење и анализу мреже за додатни контекст.

Многи наизглед мистериозни проблеми се решавају основним поступцима решавања проблема : прегледом документације, провером верзија и датума датотека, поновном инсталацијом кључних компоненти или онемогућавањем конфликтних модула. Анализирање дампа нам даје јасан смер где да тражимо и често нам штеди сате покушаја и грешака.

Такође је важно запамтити да се у окружењима попут оног које је изазвало инцидент са CrowdStrike Falcon-ом и друге EDR-ове најчешћа питања врте око тога шта је покренуло BSOD и како га брзо идентификовати . Правилно конфигурисање WinDbg-а, са симболима и јасном процедуром за отварање и анализу дампова, омогућава вам да за неколико минута сузите избор онога што би иначе могло завршити „форматирањем и поновном инсталацијом“ без правог разумевања узрока.

Укратко, комбиновање добре конфигурације дампа меморије, дисциплиноване употребе алата као што су WinDbg, Driver Verifier и Sysinternals, и навике методичког прегледа логова и стекова претвара плаве екране непредвидивог непријатеља у веома тачан извор информација о томе шта је отказало у језгру , помажући нам да доносимо много информисаније техничке одлуке.