在Windows平台上做过开发的人对Native API都不会陌生。但以Nt开头与以Zw开头的Native API到底有没有差别以及都有什么使用场景等一直以来都是让人感觉比较困扰的问题。另外内核态也有同样的一组Nt及Zw开头的内核支持函数，这两者间又是怎么一回事呢，这其中会有会有开发上有陷阱呢？！
我们先来解析用户层，然后研究下内核层其各自的实现：
用户层的Nt vs Zw
对用户层程序来说Nt与Zw开头函数实际上是一样的，只是同一个函数的两个名称而已。比如下面是对ntdll!NtCreateFile及ntdll!ZwCreateFile（Win7 X64）的反汇编：
1: kd> u ntdll!ZwCreateFile
ntdll!NtCreateFile:
00000000`77480400 4c8bd1 mov r10,rcx
00000000`77480403 b852000000 mov eax,52h
00000000`77480408 0f05 syscall
00000000`7748040a c3 ret
1: kd> u ntdll!ZwClose
ntdll!NtClose:
00000000`7747ffa0 4c8bd1 mov r10,rcx
00000000`7747ffa3 b80c000000 mov eax,0Ch
00000000`7747ffa8 0f05 syscall
00000000`7747ffaa c3 retsyscall
用户层ntdll!ZwCreateFile或NtCreateFile会通过syscall切换到内核，最早的Windows系统是通过软中断0x2e来完成模式切换的。如何切换以及切换至何处是由CPU的MSR寄存器所决定的，由操作系统在启动时完成的初始化设定。
针对Win7 X64测试系统来说，此处的syscall指令将跳转由MSR_LSTAR所指向的固定地址：
0: kd> rdmsr 0xc0000082
msr[c0000082] = fffff800`03082ec0
0: kd> u fffff800`03082ec0
nt!KiSystemCall64:
fffff800`03082ec0 0f01f8 swapgs
fffff800`03082ec3 654889242...000 mov qword ptr gs:[10h],rsp
fffff800`03082ecc 65488b242...000 mov rsp,qword ptr gs:[1A8h]
fffff800`03082ed5 6a2b push 2Bh
fffff800`03082ed7 65ff34251...000 push qword ptr gs:[10h]
fffff800`03082edf 4153 push r11
fffff800`03082ee1 6a33 push 33h
fffff800`03082ee3 51 push rcx
......
fffff800`02c7bfce 6690 xchg ax,ax
fffff800`02c7bfd0 fb sti
fffff800`02c7bfd1 48898be0010000 mov qword ptr [rbx+1E0h],rcx
fffff800`02c7bfd8 8983f8010000 mov dword ptr [rbx+1F8h],eax
nt!KiSystemServiceStart:
fffff800`02c7bfde 4889a3d8010000 mov qword ptr [rbx+1D8h],rsp
......nt!KiSystemCall64主要的工作是：
- 参数及用户栈的保存（内核态处理完打好返回用户层）
- 内核栈切换、内核线程的初始化设定等
- 准备工作做好后，最重要的是调用相应的内核服务（比如nt!NtXXX）
内核层的Nt vs Zw
对内核层来说，Zw与Nt函数虽然参数及功能上都是一致的，但二者对参数的处理及对调用环境的认同是不一样的。以nt!NtClose及nt!ZwClose的代码为例（Win7 X64）：
1: kd> u nt!NtClose
nt!NtClose [d:\w7rtm\minkernel\ntos\ob\obclose.c @ 430]:
fffff800`0338e2a0 48895c2408 mov qword ptr [rsp+8],rbx
fffff800`0338e2a5 57 push rdi
fffff800`0338e2a6 4883ec20 sub rsp,20h
fffff800`0338e2aa 65488....010000 mov rax,qword ptr gs:[188h]
fffff800`0338e2b3 48833....e9ff00 cmp qword ptr [fffff800`03227450],0
fffff800`0338e2bb 488bd9 mov rbx,rcx
fffff800`0338e2be 0fb6b8f6010000 movzx edi,byte ptr [rax+1F6h]
fffff800`0338e2c5 0f8520a70200 jne nt!NtClose+0x2a74b (fffff800`033b89eb)
fffff800`0338e2cb 400fb6d7 movzx edx,dil
fffff800`0338e2cf 488bcb mov rcx,rbx
fffff800`0338e2d2 488b5c2430 mov rbx,qword ptr [rsp+30h]
fffff800`0338e2d7 4883c420 add rsp,20h
fffff800`0338e2db 5f pop rdi
fffff800`0338e2dc e91ffdffff jmp nt!ObpCloseHandle (fffff800`0338e000)看nt!NtClose没有针对栈做任何准备工作而是直接进入了任务的处理：即调用nt!ObpCloseHandel。类似NtCreateFile也是类似的流程。
下面再来看nt!ZwClose：
1: kd> u nt!ZwClose
nt!ZwClose [o:\w7rtm.obj.amd64fre\minkernel\ntos\ke\mp\objfre\amd64\sysstubs.asm @ 267]:
fffff800`03073640 488bc4 mov rax,rsp
fffff800`03073643 fa cli
fffff800`03073644 4883ec10 sub rsp,10h
fffff800`03073648 50 push rax
fffff800`03073649 9c pushfq
fffff800`0307364a 6a10 push 10h
fffff800`0307364c 488d059d300000 lea rax,[nt!KiServiceLinkage (fffff800`030766f0)]
fffff800`03073653 50 push rax
fffff800`03073654 b80c000000 mov eax,0Ch
fffff800`03073659 e9e2670000 jmp nt!KiServiceInternal (fffff800`03079e40)
1: kd> u nt!KiServiceInternal
nt!KiServiceInternal:
fffff800`02c7be40 4883ec08 sub rsp,8
fffff800`02c7be44 55 push rbp
fffff800`02c7be45 4881ec58010000 sub rsp,158h
fffff800`02c7be4c 488da...000000 lea rbp,[rsp+80h]
fffff800`02c7be54 48899dc0000000 mov qword ptr [rbp+0C0h],rbx
fffff800`02c7be5b 4889bdc8000000 mov qword ptr [rbp+0C8h],rdi
fffff800`02c7be62 4889b5d0000000 mov qword ptr [rbp+0D0h],rsi
fffff800`02c7be69 fb sti
fffff800`02c7be6a 65488b1c2588010000 mov rbx,qword ptr gs:[188h]
fffff800`02c7be73 0f0d8bd8010000 prefetchw [rbx+1D8h]
fffff800`02c7be7a 0fb6bbf6010000 movzx edi,byte ptr [rbx+1F6h]
fffff800`02c7be81 40887da8 mov byte ptr [rbp-58h],dil
fffff800`02c7be85 c683f601000000 mov byte ptr [rbx+1F6h],0
fffff800`02c7be8c 4c8b93d8010000 mov r10,qword ptr [rbx+1D8h]
fffff800`02c7be93 4c8995b8000000 mov qword ptr [rbp+0B8h],r10
fffff800`02c7be9a 4c8d1d3d010000 lea r11,[nt!KiSystemServiceStart (fffff800`02c7bfde)]
fffff800`02c7bea1 41ffe3 jmp r11从代码上来nt!ZwClose前面做的工作则有些类似syscall，如果将syscall称作是硬模式切换的话，那nt!ZwCreate所做的可以称算是软模式切换。前者 是从用户态切换到内核态，涉及到栈及context的切换，转换成本很高。而后者则是从内核态到内核态的切换，其实仅是调用关系，均在同一个内核栈上。
nt!ZwXXX函数最终都会切换到相应的nt!NtXXX函数上，因为系统设定所有的任务都是由系统服务nt!NtXXX来实际处理。
从上面的对比不难看出，nt!ZwXXX函数做了一些看似没必要的切换工作，针对 内核驱动来说貌似完全没有必要。比如打开一个文件用nt!NtCreateFile或nt!IoCreateFile等函数更能节省稀缺的内核栈资源的使用，从这点上来看确实如此。
但二者细微的差别却可能导致严重的资源泄露问题。比如一个内核句柄，即在打开文件时指定了OBJ_KERNEL_HANDLE标志，在使用完毕要释放的时候，如果正巧是在用户context（进程上下文），比如IRP_MJ_CREATE或IRP_MJ_CLEANUP等irp的处理程序中，如果调用nt!NtClose的话，则会导致此句柄的泄露，然后此文件会一直处于打开（被占用）的状态。
其原因是nt!NtClose在处理句柄关闭时默认此句柄属于前一个模式空间（PreviousMode)。相反nt!ZwClose正因为多做了“软模式切换”，其切换过程中会修改PreviousMode为KernelMode，因为nt!ZwClose被调用时的线程已经处于内核线程模式（由用户线程通过syscall切换过来的），此时内核句柄用nt!ZwClose就能够正确关闭。
那么我们这里又有了一个新问题：如果反过来用nt!ZwClose来关闭一个本属于用户进程空间的句柄，会不会出错？
答案是不会的。因为nt!ObpCloseHandle在释放句柄前会针对内核句柄做检查，只有在满足全部条件的情况才会当作内核句柄来处理：
#define KERNEL_HANDLE_MASK ((ULONG_PTR)((LONG)0x80000000))
#define IsKernelHandle(H,M) \
(((KERNEL_HANDLE_MASK & (ULONG_PTR)(H)) == \
KERNEL_HANDLE_MASK) && \
((M) == KernelMode) && \
((H) != NtCurrentThread()) && \
((H) != NtCurrentProcess()))Object Manager通过句柄的第31位来区分是不是内核句柄，所以即使PreviousMode是KernelMode的情形也只会操作当前用户进程的句柄表（CurrentProcess->ObjectTable）而不是内核句柄表（nt!ObpKernelHandleTable）。
小结
不妨简单一点，用这样几个“简单粗暴”的公式来理解它们之间的关系，以NtClose/ZwClose为例：
- ntdll!ZwClose(用户层) = ntdll!NtClose (用户层)
- ntdll!ZwClose = syscall（硬切换） + nt!ZwClose（内核层）
- nt!ZwClose = 软切换 + nt!NtClose（内核层）
魔鬼总在细节之中 (Devils in the details) ！
<一直认为对这部分掌握得比较熟，但真正动笔的时候才发现很多不确定的地方。理解只有够深度够准确够熟练才是真正的理解！本文用时2.5小时。>
