来自这个问题：Windows Native API 如何与内核通信？
以下是ZwClose(HANDLE Handle);Windows 10 X86_64 中 NTDLL.DLL 中系统调用的示例：
NtClose proc near
mov r10, rcx
mov eax, 0Fh
test byte ptr ds:7FFE0308h, 1
jnz short loc_a
syscall
retn
loc_a:
int 2Eh
retn
NtClose endp
我的问题是，为什么会出现两种不同的指令syscall，并int 0x2E在一个子程序？的0xF在EAX值的IDZwClose()和/或NtCose()。调试时，代码执行永远不会到int 0x2E，syscall指令总是被执行并ds:7FFE0308h变为零。
7FFE0308h是KUSER_SHARED_DATA结构内的指针。
从内核模式访问的预设地址在 WDM.H 中象征性地定义为 KI_USER_SHARED_DATA。在调试时记住这在 32 位和 64 位 Windows 中分别是 0xFFDF0000 或 0xFFFFF780`00000000 会很有帮助。还定义了一个方便的符号 SharedUserData，它将这个常量地址转换为 KUSER_SHARED_DATA 指针。
共享数据的只读用户模式地址是 0x7FFE0000，在 32 位和 64 位 Windows 中都是如此。
参考：https : //www.geoffchappell.com/studies/windows/km/ntoskrnl/structs/kuser_shared_data.htm
我们从上面的引用中看到 SharedUserData+0x308 是
0x0308 ULONG 系统调用
适用于 Windows 1511 及更高版本。
那么它有什么作用呢？
//
// On AMD64, this value is initialized to a nonzero value if the system
// operates with an altered view of the system service call mechanism.
//
ULONG SystemCall;
来自最近的ntddk.h
...不是很有帮助。
那么在这种情况下int 2e 和 syscall 之间有什么区别呢？
参考：https : //twitter.com/honorary_bot/status/966609444674162688
可能是一个线索：'int 2e' 指令可以被 vmx 捕获，而 syscall 不能
更多信息：http : //blog.amossys.fr/windows10_TH2_int2E_mystery.html
在您的问题的上下文中，ntdll.dll int 0x2e系统调用可能与基于虚拟化的安全性有关。自 Windows 8 以来，它们作为系统调用方法被删除后，自版本 1511 以来，它们一直存在于 Windows 10 中。
int 2Eh用于在 32 位操作系统上进入内核模式。在 64 位上，使用syscall. 对内存地址进行的检查0x7ffe0300是检测位数的方法之一。