Контекст программного потока режима ядра
Последний возможный вариант контекста выполнения кода драйвера состоит в том, что фрагмент кода выполняется в контексте 'отдельного потока программного кода режима ядра'.
Некоторые драйверы предпочитают создавать дополнительные программные потоки для выполнения специфических задач, связанных, например, с обслуживаем устройств, которые требуют последовательного опроса (polling), или при работе в условиях, которые продиктованы специфическими схемами организации ожидания. Эти потоки, выполняющиеся в режиме ядра, не так сильно отличаются от привычных потоков пользовательского режима, подробно описанных в книгах по Win32 программированию. Они выполняются в соответствии с решениями планировщика ядра и в соответствии с присвоенными им приоритетами. Объясняется это "простое", несмотря на режим ядра, поведение тем, что создаются такие потоки вызовом PsCreateSystemThread, который может быть сделан только из кода, работающего на уровне IRQL_PASSIVE_LEVEL. Соответственно, начинают работу они на этом же уровне IRQL среди приоритетов пользовательского режима.
Такой программный поток не имеет ни собственного TEB (Thread environment block), ни контекста пользовательского режима, хотя вполне возможно, что "ответвился" от потока, у которого такой контекст имелся. Новый программный поток работает только в режиме ядра. Он не может интерпретировать виртуальные адреса, полученные из приложений пользовательского режима — даже если он их как-то получит (например, через внутренние переменные драйвера).
Как и в случае с контекстом прерываний, контекст потока, выполняющегося в режиме ядра, не может делать никаких допущений относительно выполняющихся в текущих момент процесса и потока. С позиции такого потока, таблица страничной памяти в значительной степени случайна.
