xrstor Instruction - Access Violations and General Protection Faults

I've seen this instruction cause problems quite frequently in the past, but I was still very new debugging then, and didn't know exactly what it was.

The instruction isn't easy to find with a Google search, you'll have to download the Intel Developer's Manual, if you haven't done so, then there is a copy available on my SkyDrive.

By looking at the parameters, we can see the type of exception which has happened is a Access Violation and the address of the instruction which caused the exception points to the xrstor instruction.

This is also a x64 operating system, and thereby will have a x64 processor. We can see this in the dump file with the vertarget command.

Now. let's dump the context switch and the exception.

The call stack didn't reveal to me, apart from exception handling routines. The raw stack did in fact reveal a AMD/ATI graphics card driver.

 Okay, we now have a possible candidate of why the instruction may have been used incorrectly. However, I haven't got to the point of why or how the instruction could have possibly caused the exception.

Reading through the Intel documentation, there a few reasons why the instruction can cause a General Protection Fault (read from Page 1631), but I'm going to keep this blog post to the point and show my theory of what happened.

Firstly, the xrstor instruction is used to restore a processor from a certain state, the four main processor states are from C0 to C3.

• C0 - Normal operating state
• C1 - Halt, the processor isn't executing any instructions, the privileged HLT instruction can be used to halt the processor and force it to wait for the next interrupt. The Core clock is also off here.
• C2 - Stop Clock, this is a form of standby state, whereby the processor may take longer to wake. Core and Bus clocks are off.
• C3 - Deep Sleep, clock generator is off. There is further variations of these sleep states for certain processors.

There is also processor extended states, but you will need to check the Intel documentation for this. I haven't personally checked, but Chapter 14, Section 2 seems to be the most relevant. The state information is read from a memory address specified. In this case, I believe it's the rcx register.

So, my main assumption is the memory address was not aligned to a 64-byte boundary (applies to 64-bit and 32-bit modes), leading to a access violation. 

References:

Processors - Deep and Deeper Sleep States 

Windows Data Alignment - x86 and x64

Data Alignment - Straighten Up and Fly Right

ACPI - Wikipedia