Шта је IRQL (Interrupt Request Level) у оперативном систему Windows и како је повезан са BSOD-има?

Ако сте икада видели плави екран са порукама попут ИРКЛ_НОТ_ЛЕСС_ОР_ЕКУАЛ o DRIVER_IRQL_NOT_LESS_OR_EQUAL, вероватно сте наишли на концепт који је мало познат ван света драјвера: IRQL (Interrupt Request Level - ниво захтева за прекид). виндовс, овај ниво приоритета прекида има предност над приоритетом нити када је систем изнад одређеног прага, а то има директне последице по стабилност.

У наредним редовима ћете пронаћи уна потпун водич и на шпанском из Шпаније о томе шта је IRQL, како функционише, зашто покреће плаве екране, како дијагностиковати проблем са WinDbg-ом и шта да радите без обзира да ли сте корисник који има грешку или развијате драјвере у режиму језгра. Хајде да се бацимо на посао.

Шта је IRQL (ниво захтева за прекид) у оперативном систему Windows?

У оперативном систему Виндовс, IRQL дефинише приоритет хардвер на којем процесор ради у било ком тренутку. У оквиру Windows Driver Model-а (WDM), код који се извршава на ниском IRQL-у може бити прекинут кодом који се извршава на вишем IRQL-у. У ствари, на једном вишејезгарном рачунару, сваки CPU може бити на другом IRQL-у, што компликује синхронизацију.

Постоји једно кључно правило: Када процесор ради на IRQL-у изнад PASSIVE_LEVEL, може бити превазиђен само активношћу на још вишем IRQL-у.Ово организује коегзистенцију између корисничког кода, функција језгра, одложених позиваоца (DPC) и рутина за прекид уређаја (ISR).

Нивои и приоритети: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL и DIRQL

У општим цртама, На x86, користе се IRQL вредности између 0 и 31; на x64, између 0 и 15Практично значење је исто: IRQL 0 (PASSIVE_LEVEL) је место где се извршава нормалан кориснички код и многе функције драјвера; APC и грешке странице Обично су мапирани на IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) обухвата распоређивач нити и DPC-ове. Изнад DISPATCH_LEVEL су нивои резервисани за прекиде уређаја (познати као DIRQL) и друге интерне употребе као што је HIGH_LEVEL.

У екосистему возача, Многе уобичајене рутине се извршавају на DISPATCH_LEVELна пример, DPC и StartIo. Овај дизајн осигурава да док један од њих додирује интерне редове или друге дељене ресурсе, друга рутина на истом нивоу га не преузима на том процесору, јер правило преузимања дозвољава прекиде само на вишим нивоима.

Између DISPATCH_LEVEL и профилисања/високих нивоа постоји простор за хардверски прекиди сваког уређаја (DIRQL)IRQL уређаја дефинише његов приоритет у односу на друге уређаје. WDM драјвер добија овај IRQL током IRP_MJ_PNP са IRP_MN_START_DEVICE. Овај IRQL уређаја није глобална, фиксна вредност, већ вредност повезана са одређеном линијом прекида.

IRQL у односу на приоритет нити

Препоручљиво је не мешати концепте: Приоритет нити одређује када распоређивач преузима задатак и која нит се извршава; IRQL контролише која врста активности може да се изврши и који прекиди су маскирани. Изнад DISPATCH_LEVEL, нема пребацивања нити: IRQL контролише, а не приоритет нити.

IRQL и странично позивање: Шта не би требало да радите

Непосредни ефекат повећања IRQL-а је да систем не може да обрађује грешке страницеЗлатно правило: код који се извршава на или изнад DISPATCH_LEVEL не може изазвати грешке страница. У пракси то значи да те рутине и подаци којих се дотичу мора се налазити у нестраничној меморијиПоред тога, одређени помоћници језгра ограничавају своју употребу на основу IRQL-а: на пример, KeWaitForSingleObject DISPATCH_LEVEL може бити позван само ако не блокирате (нулто време чекања), а за временске истеке које нису нулте, морате бити испод DISPATCH_LEVEL.

Имплицитна и експлицитна контрола IRQL-а

Већину времена, систем сам позива ваше рутине на исправном IRQL-у за оно што би требало да раде. Рутине отпреме за IRP-ове се извршавају на PASSIVE_LEVEL (могу да блокирају или позову било ког помоћника), StartIo и DPC се извршавају на DISPATCH_LEVEL да би заштитили дељене редове, а ISR-ови се извршавају на DIRQL.

Ако је потребно да га експлицитно контролишете, Можете повећати и смањити IRQL помоћу KeRaiseIrql y KeLowerIrqlПостоји једна веома коришћена пречица: KeRaiseIrqlToDpcLevel() враћа претходни IRQL и оставља вас на DISPATCH_LEVEL. Важно: Никада не спуштајте IRQL испод вредности коју је имао када вас је систем позвао; кршење те синхронизације може отворити веома озбиљне прозоре трке.

Грешке плавог екрана повезане са IRQL-ом: IRQL_NOT_LESS_OR_EQUAL и DRIVER_IRQL_NOT_LESS_OR_EQUAL

Две класичне провере грешака повезане са овим проблемима су IRQL_NIJE_MANJI_ILI_JEDNAKI (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Оба указују на покушај приступа страничној (или неважећој) адреси на IRQL-у који је превисок. Ово је обично због тога што драјвери користе нетачне адресе, дереференцирају лоше показиваче или извршавају странично код на неодговарајућим нивоима.

У конкретном случају DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1), параметри су веома информативни: 1) референцирана меморијска адреса; 2) IRQL у том тренутку; 3) тип приступа (0 читање, 1 писање, 2/8 извршавање); 4) адреса инструкције која је референцирала меморију. Са дебагером можете користити ln на параметру 4 за наведите најближи симбол и сазнајте која је функција била извршавана.

Уобичајени узроци које треба имати на уму

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

Други уобичајени случајеви укључују позовите функцију у другом драјверу који је већ преузет (висећи показивач функције) или индиректно позван преко неважећег показивача функције. Често, ако је систем у стању да идентификује модул, видећете његово име на самом плавом екрану, а такође је сачуван и у KiBugCheckDriver, доступно са dx KiBugCheckDriver из WinDbg-а.

Практичан детаљ: У већини D1/A, прави проблем није сам IRQL, већ референцирана меморијска адреса. Зато су параметри 1, 3 и 4 кључни за фокусирање дијагнозе.

Дијагностика помоћу WinDbg-а: Корисне команде и читање параметара

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

Л команде гомиле као k, kb, kc, kd, kp, kP, kv Они вам приказују различите нивое детаља уназадног трага. Са ln на параметру 4 можете прескочити инструкцији која је референцирала меморију и добијте оближњи симбол. А ако сумњате да је ниво приоритета покренут пре прекида, !irql приказује вам сачувани IRQL за циљни процесор (нпр. DISPATCH_LEVEL).

Да би се анализирао смер параметра 1, !pool Рећи ће вам да ли припада страниченом пулу; !address y !pte зароните у мапирање меморије тог подручја. Можете користити команде за приказ меморије да прегледа садржај коме је покушано приступити. Коначно, u, ub, uu омогућавају вам да растављате око адресе параметра 4.

Не заборави lm t n да наведете учитане модуле y !memusage за опште стање памћења. Ако KiBugCheckDriver има нешто, dx KiBugCheckDriver Вратиће име Unicode модула: у типичном примеру, „Wdf01000.sys“ је виђен као драјвер укључен током провере грешака.

Системски алати: Провера драјвера, Прегледач догађаја и Дијагностика

El Верификатор драјвера Испитује понашање драјвера у реалном времену и форсира грешке када детектује нетачно коришћење ресурса (као што је базен), избацујући изузетак да би изоловао проблематично подручје кода. Покреће се са verifier од командни редак и препоручљиво је одабрати што мањи скуп драјвера како би се избегло превелико оптерећење.

Ако себе не видите са WinDbg-ом, применити основне мереПроверите системски дневник у Прегледачу догађаја да ли постоје грешке које указују на одређени уређај/драјвер; ажурирајте или онемогућите драјвер који је наведен плавим екраном; проверите компатибилност хардвера са вашом верзијом оперативног система Windows; и користите Windows Memory Diagnostic ако сумњате на RAM. Ове радње, иако једноставне, решавају велики број случајева.

Случајеви из стварног живота: Када BSOD-ови делују случајно

Корисник са Windows 10 Pro (AMD Ryzen 5 3400G CPU, ГПУ АМД GeForce GTX 1660 Ti и Gigabyte B450 AORUS PRO WIFI плоча, 16 GB RAM-a) је повремено добијао поруке „IRQL_LESS_OR_NOT_EQUAL“. Већ сам ажурирао основне драјвере (мрежу, графику), инсталирао сва Windows ажурирања и покренуо алатку за меморију, све без икаквих проблема.

У сценаријима попут овог, Следећи корак је анализа дампова помоћу WinDbg-а и потражите обрасце: процесе који се дешавају када падне (на пример explorer.exe), модули графичког интерфејса (win32kfull.sys) и функције као што су xxxProcessNotifyWinEvent појављују се у стеку. Иако је овај модул Windows, окидач је често драјвер треће стране (графика, улаз, преклапање, картице за снимање) који користи меморију на неодговарајућем IRQL-у и грешка настаје унутар win32k.

Практична препорука овде је привремено онемогућите софтвер за преклапање (снимање, GPU OSD), агресивне софтверске периферне драјвере (мишеви/тастатуре са макроима) и бета верзије графичких драјвера и сузите избор. Коришћење алатке за проверу драјвера на сумњивим уређајима може помоћи у сужавању проблема са јаснијим стеком.

Веома чест мрежни образац: ndis.sys није увек кривац

Још један типичан случај: снимак екрана са ndis.sys (Windows мрежни слој). На стварном рачунару, систем би се срушио одмах по покретању. Практично решење је било покретање у Безбедан режим без мрежних функција, отворите Управитељ уређаја и онемогућите адаптере у одељку „Мрежни адаптери“ да бисте изоловали проблем.

У том тиму је био Realtek PCIe GBE Family контролер и Atheros AR5007GДеактивирањем оба, откривено је да је прави узрок био athrx.sys (Атерос), иако је плави екран поменуо ndis.sysДамп је то потврдио: стек је прошао кроз ndis!NdisFreeTimerObject али је кривични модул био athrx.sysКоначна корекција је била Деинсталирајте уређај и инсталирајте ажуриране званичне драјвере Са веб странице произвођача Atheros-а. Поука: Модул наведен у BSOD-у може бити део погођеног подсистема, а не извор.

Типичан одговор подршке и брзи кораци за кориснике

У искреној размени подршке, техничар је одговорио: „Жао ми је због непријатности. Могуће је да је проблем у вези са драјвером, меморијом или антивирусом. Ажурирајте драјвере и, ако се проблем настави, покрените дијагностику меморије.“Ово је основни, али валидан савет; међутим, ако грешке и даље постоје, добра је идеја да се настави са верификатором и анализом дампа.

За кориснике који нису технички потковани, разуман протокол би био: 1) Проверите системске догађаје, 2) Ажурирајте кључне драјвере (чипсет/мрежа/графика), 3) Проверите РАМ меморију са интегрисаним алатом, 4) тестирајте боот чисто без софтвера треће стране који убацује закачке у језгро/ГУИ, и 5) користите Верификатор на драјверима треће стране ако ништа није јасно.

Најбоље праксе за програмере драјвера

Ако развијате и наиђете на D1/A, проверите да ли је Покренута рутина није означена као страницабилна Не позивајте функције које се могу страничити док се извршавају на нивоу DISPATCH_LEVEL или вишем. Ово укључује избегавање референци на податке у страниченим одељцима и поштовање IRQL ограничења за помоћне функције језгра описане у DDK-у.

Да бисте синхронизовали дељене податке, примени правило „увек приступај дељеним подацима са истим високим IRQL-ом“ и користите спин-браве када је то прикладно. На мултипроцесорским системима, сам IRQL не гарантује искључивање између различитих CPU-а; спин-браве подижу IRQL (на DISPATCH_LEVEL) и координирају приступ између језгара. Ако треба да радите на осетљивим хардверским регистрима, KeSynchronizeExecution помаже вам да извршите критичне секције на исправном DIRQL-у.

Када план захтева повећање IRQL-а, САД KeRaiseIrqlToDpcLevel за НИВО_ОТПРАВЉАЊА или KeRaiseIrql пажљиво, чување претходног IRQL-а и његово враћање тачно са KeLowerIrqlИдите испод улазног IRQL-а, чак и само на тренутак, То је озбиљна грешка у синхронизацији.

Однос са прекидима и хардвером

IRQL је механизам којим Windows наређења прекидају приоритете и одређене интерне задаткеНа архитектонском нивоу, то је повезано са концептима као што су „Прекид“, „Руковалац прекидима“ или „Ниво приоритета прекида“ и, на класичним платформама, са Програмабилни контролер прекида (ПИЦ)У другим системима, контрола приоритета се изражава путем механизама као што су спл en уник; општа идеја је иста: ко може кога прекинути.

Напредни савети за отклањање грешака

У дамповима где стек указује на win32kfull!xxxProcessNotifyWinEvent са провером грешака 0xA/0xD1, проверите контекст са .process y .thread (ако је доступно), погледајте процесе као што су explorer.exe en !process 0 1 и проверите преклапања и драјвере за интеракцију са графичким корисничким интеракцијским сервисом. Много пута је проблем То је сећање које је оштетила трећа страна која се појављује на тој рути.

Не заборавите да проверите IRQL са !irql, и контраст: ако сте на DISPATCH_LEVEL (2) и параметар 3 означава читање/писање/извршавање На страници која се може поделом по страницама, већ имате назнаку зашто је пала. Укрстите ту назнаку са ln у параметру 4 да би се добила специфична функција.

Схвати Шта је IRQL? и како се уклапа у извршавање језгра помаже у одвајању шума од сигнала. Ако сте корисник, фокусирајте се на драјвери и хардвер (са Verifier-ом, догађајима и тестовима по подразумеваним подешавањима). Ако развијате, строго се придржавајте правила за IRQL, нестраничну меморију и синхронизацију са spin lock-овима. Уз одговарајуће алате (WinDbg, Verifier) ​​и пажљиво читање параметара (1, 3 и 4), Ове провере грешака више нису мистерија. и они постају проблеми који се могу методично решити.