Выходит, если HalHandleNMI - самый низкоур-й nmi обработчик, то осталось выяснить когда его вызывают в новой задаче?

[ volodya: а что SwapContext в ядре? Там идет работа с KTSS ]

По маленьку.

SwapContext proc
. . .
:0040261E loc_40261E:
:0040261E       mov ecx, [ebx+KPCR.TSS]
:00402621       mov [ecx+KTSS.Esp0], eax		; eax = KTHREAD.InitialStack - sizeof FX_SAVE_AREA
. . .
:00402651       mov eax, [edi+KPROCESS.DirectoryTableBase]
:00402654       mov ebp, [ebx+KPCR.TSS]
:00402657       mov ecx, dword ptr [edi+KPROCESS.IopmOffset]
:0040265A       mov [ebp+KTSS.CR3], eax
:0040265D       mov cr3, eax
:00402660       mov [ebp+KTSS.IoMapBase], cx
. . .
SwapContext endp

[ volodya: Итак, KPCR - один на всех. Просто в нужный момент времени берется информация из списка KTHREAD и переписываются поля KPCR. Я прав? ]

Да. В KiSwapThread и KiReadyThread (может ещё где).

Four-F

Не согласен с тобой. Мотивируй.
Смотри. Ты говоришь, KPROCESS, я говорю, KTHREAD. Винда работает с потоками, а не с процессами.
Далее, перезагрузка CR3 для меня вопросом и не была. Меня застрелили вещи ниже. Вот эти:

.text:0040440A                 mov     ebp, [ebx+3Ch]  ; KPCR.GDT
.text:0040440D                 mov     eax, [edi+KTHREAD.Teb]
.text:00404410                 mov     [ebp+48h], eax  ;???
.text:00404413                 mov     eax, [edi+KTHREAD.TlsArray]
.text:00404416                 mov     [ebp+4Ch], eax ;???
.text:00404419                 mov     eax, 48h
.text:0040441E                 mov     ebp, [ebx+38h]  ; KPCR.IDT
.text:00404421                 mov     ecx, [edi+KTHREAD.KernelStack]
.text:00404424                 mov     [ebp+108h], ecx
.text:0040442A                 mov     ecx, dword ptr [edi+KTHREAD.DebugActive]
.text:0040442D                 mov     [ebp+10Ch], ecx
.text:00404433                 lldt    ax

[ volodya: Ты говоришь, KPROCESS, я говорю, KTHREAD. ]

Именно KPROCESS. При входе в SwapContext edi и esi кажут на KTHREAD потоков, с которого переключаться, и на который переключаться (или наоборот - базы под рукой нет). Но затем в edi помещается указатель на KPROCESS.


[ volodya: Винда работает с потоками, а не с процессами. ]

Если быть более точным, то когда винде надо поработать с процессом она работает с процессом, а когда с потоком, то она с ним и работает. Короче, она сама знает с чем ей работать :-) В том куске кода, который я привёл edi кажет на KPROCESS 100%. Это даже требует доказательства, т.к. DirectoryTableBase является атрибутом процесса, а не потока - Page Table Directory один на все потоки внутри процесса. Затем DirectoryTableBase помещается в cr3. Тут всё чисто. А в твоём куске заполняется дескриптор 48h в GDT (потом загружается в LDTR) и дескриптор для прерывания 21h в IDT. Этот кусок кода для 16-битных прог.

.text:00402698 loc_402698:                   ; SwapContext+A8h
.text:00402698       mov ebp, [ebx+KPCR.GDT]
.text:0040269B       mov eax, dword ptr [edi+KPROCESS.LdtDescriptor.LimitLow]
.text:0040269E       mov [ebp+48h], eax      ; Fill Low Part of LDT Descriptor
.text:004026A1       mov eax, [edi+KPROCESS.LdtDescriptor.HighWord.Bits.BaseHi]
.text:004026A4       mov [ebp+4Ch], eax      ; Fill High Part of LDT Descriptor
.text:004026A7       mov eax, 48h            ; eax = LDT Selector
.text:004026AC       mov ebp, [ebx+KPCR.IDT]
.text:004026AF       mov ecx, dword ptr [edi+KPROCESS.Int21Descriptor.Offset]
.text:004026B2       mov [ebp+108h], ecx     ; Fill Low Part of 21 Interrupt Gate Descriptor
.text:004026B8       mov ecx, dword ptr [edi+KPROCESS.Int21Descriptor.Access]
.text:004026BB       mov [ebp+10Ch], ecx     ; Fill High Part of 21 Interrupt Gate Descriptor
.text:004026C1       lldt ax                 ; Load LDTR = 48h

Поставь туда бряк и запусти любую досовую прогу, hiew.exe например.

и это ведь правда. разница лишь в том, что при преключении потоков н перегружается база каталога страниц, а так всё то же самое.