Hardware task switching within Windows

[Kamala]

Within Windows I modified the GDT to include an entry for a new TSS segment, code, data segment etc. and attempted a far jump to the new task I created. This results in a GP fault. Per specification, a GP fault is expected in this scenario when -

1) The TSS segement is not present. Or,
2) When the busy flag is set in the TSS descriptor.

I confirmed neither of the above to be the case. Anything obvious I am missing? Or, does anyone have any suggestion as to how I might better investigate this problem? Thanks.

[js]

Maybe I'm totally misunderstanding you, but if by "within Windows" you mean "while MS Window$ was running", then it's surely that you aren't in ring 0, so you don't have the rights to do this operation.

[Kamala]

Yes, I am doing this within Windows. To be precise, I am modifying the GDT from within a Windows kernel driver that runs in ring0. While listing the GDT entries within a debugger I see the newly added entry for TSS and other segments. So I know they exist and the GP fault can't be because of non existing TSS descriptor. TSS busy flag is also not set. So, the GPF can't be because of that either. I am a little lost as to what might be causing the GPF as these are the two possible things that could cause a GPF while switching tasks (per specification).

[NickJohnson]

Any particular reason you're developing literally from within Windows? It seems like undue hassle (and danger) when compared to a typical VM setup.

[gerryg400]

You need to look at the error code for a hint.

[Kamala]

I need to perform a task out of band without winding down Windows and hardware task switching seemed like a good feature to capitalize on for that purpose.

[Kamala]

I did look at the error code. It is unexpected kernel mode trap (0x7f) with 0xd as argument 0 (GP fault).

[gerryg400]

GP fault has an error code. It will tell you the selector that caused the error and some other limited info.

[Kamala]

How would I get to the other limited error information? All I get is a 0x7F for bug check code with param 0xd and nothing else. Crash dump also doesn't give much else except for the location which I already know to be the far jump instruction to switch task.

[gerryg400]

The errorcode is pushed on the stack by the processor. Maybe you can find it there if windows didn't pop it off.

[Kamala]

That's an interesting piece of information. Thanks much!

Rummaging through the stack I do see something that looks like a selector, possibly for the code segment I am associating with the task. I will confirm that.