Deadlock при вызове NtGetContextThread

при попытке подменить KPROCESSOR_MODE на UserMode PsGetContextThread проверяет адрес параметра CONTEXT Context на юзермодность, во всяком случае в checked build. поэтому я переделал все через sysenter. спасибо всем, принявшим участие в дискурсии

 

Читая этот бред возникает улыбка. Походу отписавшие в данном топике не понимают что есть контекст. Матчасть: контекст - более высокоуровневый аналог хардварного состояния задачи(T-фрейм), который позволяет освободится от привязки к версиям. Например T-фрейм не содержит состояния дополнительных блоков(FPU, SSE.. в общем называемых NPX). Контекст содержит эти блоки, это полное состояние задачи.
Состояние задачи сохраняется при межкольцевых переключениях в сторону меньшего CPL. Таким образом поток, вошедший в ядро сам сохраняет своё состояние и разрешает доступ к нему, взводя IF(прерывания размаскируются). В это время и до возврата в юзермод т-фрейм доступен. Для конвертации его в контекст есть две функции - KeContextToKframes & KeContextFromKframes. Чтение контекста текущего потока сводится к извлечению т-фрейма с его дна. Для удалённых потоков чтение контекста производится посредством доставки апк, из которой выполняется чтение локального т-фрейма(апк локальна) и конвертация его в контекст.
В связи со всем этим, поток сменивший окружение доступен в любой момент через низкоуровневые функции, работающие с т-фрефмами. Более высокоуровневые функции могуи вызывать дедлоки(увы сурсов щас под рукой нет, в инет кафе нихире нет даже админских прав, хотя пасс подходит ко всем машинам в беларуси повсеместно, винда ведь пiжженая).

 

извини билл, мы тебя сразу не признали. богатым будешь
ps на хрена ты это написал?

 

пути GPE неисповедимы