Es complicado. ;)
No, realmente lo es.
IRQL significa "Nivel de solicitud de interrupción". Es un número, que va del 0 al 31 en sistemas Windows x86 y del 0 al 15 en sistemas x64. Representa la "importancia" de una tarea en modo kernel en relación con otras tareas en modo kernel.
IRQL es un estado del procesador definido por Windows, no de un proceso o subproceso, que indica a Windows si lo que está haciendo ese procesador puede ser interrumpido por otras tareas. Si una nueva tarea (como una rutina de servicio de interrupción) tiene un IRQL más alto que el IRQL actual del procesador, entonces sí, puede interrumpir la tarea actual; De otra manera no. En un sistema multiprocesador, cada procesador tiene su propio IRQL. Esto incluye los "Procesadores lógicos" creados por hyperthreading.
(Uso la palabra "importancia" en lugar de "prioridad" porque "prioridad" en Windows se refiere a prioridades de subprocesos, y los IRQL son algo diferente. A diferencia de las prioridades de subprocesos, las tareas del núcleo en el mismo IRQL no están divididas en el tiempo, y los IRQL no lo son. t sujeto a refuerzo y descomposición automáticos.)
(También debería mencionar que el término "tarea de kernel" aquí no es oficial. Windows realmente no llama a estas cosas "tareas de kernel", no son objetos administrados como lo son, por ejemplo, procesos y subprocesos, y no hay relación con la tarea x86 " "ni a nada de lo que se muestra en" Administrador de tareas ". Como yo (y otros) utilizamos el término aquí," la tarea en modo kernel "realmente cubre" cualquier cosa con un principio y un final definidos que deba hacerse en modo kernel en IRQL 2 o "Una rutina de servicio de interrupción es un ejemplo de una" tarea en modo kernel "; también lo es una rutina DPC. Pero otro ejemplo puede ser el código en un hilo en modo kernel. Estos hilos comienzan en IRQL 0, pero si son parte del código planteaa IRQL 2 o superior, hace algo y luego regresa a su IRQL anterior, la parte de alto IRQL del código es un ejemplo de lo que estoy llamando una "tarea del núcleo" aquí. )
El Monitor de rendimiento muestra el tiempo pasado en IRQL 2 como "% de tiempo de DPC" y el tiempo en IRQL> 2 como "% de tiempo de interrupción", independientemente de si el tiempo se pasó realmente en una rutina DPC o ISR o fue el resultado de aumentar IRQL de Un valor más bajo. Cada uno es un subconjunto de lo que PerfMon muestra como "% de tiempo privilegiado", que debería haberse etiquetado como "tiempo de modo kernel".
Una vez que se inicia una tarea del núcleo en IRQL 2 o superior, se ejecuta hasta su finalización antes de que cualquier otra cosa en el mismo IRQL se inicie en el mismo procesador. Puede ser interrumpido por una tarea de IRQL superior (que a su vez podría ser interrumpida por una tarea de IRQL aún mayor, etc.), pero cuando se completan las tareas de IRQL superior, el control vuelve a la tarea que interrumpió.
IRQL es principalmente un mecanismo de serialización . (Muchos dicen "sincronización", pero prefiero esta palabra, ya que describe más exactamente el resultado). Su propósito es ayudar a garantizar que múltiples tareas en la misma CPU accedan a ciertos recursos compartidos, en su mayoría estructuras de datos compartidos en el espacio del núcleo del sistema operativo, no están autorizados a interrumpirse entre sí de manera que puedan corromper esas estructuras.
Por ejemplo, una gran cantidad de datos en el kernel de Windows, particularmente los datos de administración de memoria y los datos utilizados por el planificador de subprocesos, se "serializan" en IRQL 2. Eso significa que cualquier tarea que desee modificar dichos datos debe ejecutarse en IRQL 2 cuando lo hace. Si una tarea con un IRQL superior intenta escribir dichos datos, eso podría causar corrupción, ya que podría haber interrumpido una tarea IRQL 2 que podría estar en medio de un ciclo de lectura-modificación-escritura en esos mismos datos. Por lo tanto, las tareas con IRQL superior simplemente no pueden hacer eso.
Las tareas de mayor IRQL son principalmente las rutinas de servicio de interrupción de los controladores de dispositivos, porque todas las interrupciones de los dispositivos ocurren en IRQL> 2. Esto incluye la interrupción del chip temporizador en la placa base que impulsa el cronometraje y la actividad controlada por el tiempo en el sistema operativo. Su IRQL está por encima de todos los dispositivos de hardware "ordinarios".
Las IRQL 2 y superiores se usan para tareas del núcleo que no se activan por interrupciones de hardware pero durante las cuales no puede ocurrir la programación normal de subprocesos, incluida la espera. Por lo tanto, una vez que un procesador está en IRQL 2 o superior, no se pueden realizar cambios de contexto de subproceso en ese procesador hasta que IRQL caiga por debajo de 2.
El código de modo de usuario siempre está en IRQL 0. El código de modo de núcleo puede ejecutarse en cualquier IRQL desde 0 hasta el valor máximo. IRQL 1 es un caso especial; es solo el modo kernel, pero no tiene ningún impacto en la programación, y es realmente más un estado de un subproceso que del procesador: se guarda y restaura durante los cambios de contexto del subproceso, por ejemplo.
Para mantener varias garantías de serialización, la mayoría de las excepciones (cosas como dividir por cero o violaciones de acceso a la memoria como fallas de página) simplemente no son manejables en IRQL 2 o superior. (IRQL 2 por cierto se llama comúnmente "nivel de despacho" o "nivel DPC").
¡Y ahora finalmente podemos explicar este código de comprobación de errores!
El caso más común de IRQL_NOT_LESS_OR_EQUAL se debe a un error de página (intento de acceder a una dirección virtual "no residente") o una violación de acceso a la memoria (intento de escribir en una página de solo lectura o acceder a una página que no está definida en absoluto), eso ocurre en IRQL 2 o superior.
Si tales excepciones se generan en IRQL 0 o 1, pueden "manejarse" ya sea por código proporcionado por el sistema (como el manejador de fallas de página) o por un manejador de excepciones provisto por el desarrollador. Sin embargo, la mayoría de las excepciones no pueden manejarse en absoluto si ocurrieron en IRQL 2 o superior.
Entonces ... el código de comprobación de errores significa "una excepción de un tipo que solo puede manejarse en IRQL 0 o 1 ocurrió cuando IRQL estaba en 2 o más". es decir, "no menor o igual que 1". Redacción extraña, pero ahí está.
Hay algunas otras cosas que pueden desencadenar esta comprobación de errores, y el valor con el que el IRQL no es menor o igual no siempre es 1, pero ocurren solo en raras ocasiones. La documentación de WinDBG los enumera.