Under certain conditions, the processor generates a # UD using the prefix Lock. ISR KiTrap06 handles the exception and, depending on the availability prefix Lock returns STATUS_ILLEGAL_INSTRUCTION or STATUS_INVALID_LOCK_SEQUENCE. In XP, the ISR mistake, simple search in the first 4 bytes of instruction and prefix Lock, if it is found returns STATUS_INVALID_LOCK_SEQUENCE. Ie for instructions ud2/Lock/.. will be thrown with the code STATUS_INVALID_LOCK_SEQUENCE. The kernel looks for the prefix after the instructions
In W7 mechanism changed. Searches for a prefix Lock in the first 5 bytes of instruction, and search through sequential extraction byte instructions and scan the table prefixes. Ie an exception with code STATUS_INVALID_LOCK_SEQUENCE generated only if among the first 5 prefix is a prefix Lock, otherwise an exception is thrown with the code STATUS_ILLEGAL_INSTRUCTION. This happens on XP with ISR #GP(KiTrap0D) - checked 15 bytes for the presence of a prefix and if it is not returned STATUS_ILLEGAL_INSTRUCTION, otherwise the code is returned STATUS_PRIVILEGED_INSTRUCTION. In fact it does nothing, only unnecessary problems in the processing of exceptions (the most terrible is the trace exception manager). We antiviral emulators with this problem
AVG simulates the generation of exceptions STATUS_INVALID_LOCK_SEQUENCE, if you have at least one prefix Lock.
Example: http://paste.org.ru/?lwfzkv