È complicato. ;)
No, davvero.
IRQL sta per "Livello di richiesta di interruzione". È un numero che va da 0 a 31 su sistemi Windows x86 e da 0 a 15 su sistemi x64. Rappresenta l '"importanza" di un'attività in modalità kernel rispetto ad altre attività in modalità kernel.
IRQL è uno stato del processore definito da Windows - non di un processo o thread - che indica a Windows se qualunque cosa stia facendo quel processore può essere interrotta o meno da altre attività. Se una nuova attività (come una routine di servizio di interruzione) ha un IRQL superiore rispetto all'IRQL corrente del processore, allora sì, può interrompere l'attività corrente; altrimenti no. Su un sistema multiprocessore ogni processore ha il proprio IRQL. Ciò include i "Processori logici" creati dall'hyperthreading.
(Uso la parola "importanza" piuttosto che "priorità" perché "priorità" in Windows si riferisce alle priorità dei thread e gli IRQL sono qualcosa di diverso. A differenza delle priorità dei thread, le attività del kernel nello stesso IRQL non sono suddivise nel tempo e gli IRQL non sono " t soggetto a boost e decadimento automatici.)
(Dovrei anche menzionare che il termine "attività del kernel" qui non è ufficiale. Windows non chiama queste cose "attività del kernel", non sono oggetti gestiti come lo sono processi e thread, e non c'è alcuna relazione con l'attività x86 " gates "né a qualsiasi cosa mostrata in" Task Manager ". Dato che io (e altri) uso il termine qui," task in modalità kernel "copre davvero" tutto con un inizio e una fine definiti che devono essere fatti in modalità kernel su IRQL 2 o sopra. "Una routine di servizio di interruzione è un esempio di" attività in modalità kernel "; così è una routine DPC. Ma un altro esempio può essere il codice in un thread in modalità kernel. Tali thread iniziano con IRQL 0, ma se parte del codice rilancia IRQL 2 o versioni successive, fa qualcosa e poi ritorna al suo precedente IRQL, la parte alta del codice IRQL è un esempio di ciò che sto chiamando un "task kernel" qui. )
Performance Monitor mostra il tempo trascorso su IRQL 2 come "% tempo DPC" e il tempo su IRQL> 2 come "% tempo di interruzione", indipendentemente dal fatto che il tempo sia stato effettivamente impiegato in una routine DPC o ISR o sia stato il risultato di aumentare IRQL da un valore inferiore. Ciascuno è un sottoinsieme di ciò che PerfMon mostra come "% tempo privilegiato" - che avrebbe dovuto essere etichettato "tempo in modalità kernel".
Una volta che un'attività del kernel viene avviata su IRQL 2 o versioni successive, viene eseguita fino al completamento prima che qualsiasi altra cosa sullo stesso IRQL venga avviata sullo stesso processore. Può essere interrotto da un'attività IRQL superiore (che a sua volta potrebbe essere interrotta da un'attività IRQL ancora superiore, ecc.), Ma quando le attività IRQL superiori vengono completate, il controllo ritorna all'attività interrotta.
IRQL è principalmente un meccanismo di serializzazione . (Molti dicono "sincronizzazione", ma preferisco questa parola perché descrive più esattamente il risultato.) Il suo scopo è di aiutare a garantire che più attività sulla stessa CPU accedano a determinate risorse condivise - principalmente strutture di dati condivise nello spazio del kernel del sistema operativo - non sono autorizzati ad interrompersi a vicenda in modo tale da corrompere tali strutture.
Ad esempio, una grande quantità di dati nel kernel di Windows, in particolare i dati di gestione della memoria e i dati utilizzati dallo scheduler dei thread, sono "serializzati" su IRQL 2. Ciò significa che qualsiasi attività che desidera modificare tali dati deve essere in esecuzione su IRQL 2 quando lo fa. Se un'attività IRQL superiore tenta di scrivere tali dati, ciò potrebbe causare la corruzione, poiché potrebbe aver interrotto un'attività IRQL 2 che potrebbe trovarsi nel mezzo di un ciclo di lettura-modifica-scrittura su quegli stessi dati. Quindi le attività con IRQL superiori non possono semplicemente farlo.
Le attività IRQL superiori sono principalmente le routine di servizio di interrupt dei driver di dispositivo, poiché tutti gli interrupt dei dispositivi si verificano in IRQL> 2. Ciò include l'interruzione dal chip del timer sulla scheda madre che guida il cronometraggio e l'attività basata sul tempo nel sistema operativo. Il suo IRQL è superiore a quello di tutti i dispositivi hardware "ordinari".
Gli IRQL 2 e successivi sono usati per le attività del kernel che non sono attivate da interruzioni hardware ma durante le quali non può avvenire la normale programmazione dei thread - inclusa l'attesa. Pertanto, una volta che un processore si trova su IRQL 2 o versioni successive, su quel processore non possono verificarsi interruzioni di contesto del thread finché IRQL non scende al di sotto di 2.
Il codice della modalità utente è sempre su IRQL 0. Il codice della modalità kernel può essere eseguito su qualsiasi IRQL da 0 a qualunque sia il massimo. IRQL 1 è un caso speciale; è solo la modalità kernel, ma non ha alcun impatto sulla pianificazione, ed è in realtà più uno stato di un thread che del processore - ad esempio, viene salvato e ripristinato durante i cambi di contesto del thread.
Al fine di mantenere varie garanzie di serializzazione, la maggior parte delle eccezioni (cose come dividere per zero o violazioni dell'accesso alla memoria come errori di pagina) non sono semplicemente gestibili su IRQL 2 o versioni successive. (IRQL 2 btw è comunemente chiamato "livello di spedizione" o "livello DPC".)
E ora possiamo finalmente spiegare questo codice bugcheck!
Il caso più comune di IRQL_NOT_LESS_OR_EQUAL è dovuto a un errore di pagina (tentativo di accedere a un indirizzo virtuale "non residente") oa una violazione dell'accesso alla memoria (tentativo di scrivere su una pagina di sola lettura o di accedere a una pagina non definita affatto), ciò si verifica in IRQL 2 o versioni successive.
Se tali eccezioni vengono sollevate su IRQL 0 o 1, possono essere "gestite" tramite il codice fornito dal sistema (come il gestore degli errori di pagina) o da un gestore delle eccezioni fornito dallo sviluppatore. Tuttavia, la maggior parte delle eccezioni non può essere gestita affatto se si verificano in IRQL 2 o versioni successive.
Quindi ... il codice bugcheck significa "un'eccezione di un tipo che può essere gestita solo su IRQL 0 o 1 si è verificata quando IRQL era a 2 o superiore". cioè "non inferiore o uguale a 1". Strana formulazione, ma eccola qui.
Ci sono alcune altre cose che possono attivare questo controllo errori e il valore a cui IRQL non è inferiore o uguale non è sempre 1, ma si verificano solo raramente. La documentazione di WinDBG li elenca.