为什么WinDBG可在nt!NtCreateFile断下，却无法在nt!NtAccessCheck等函数断住？

问题原因 #

出现该问题是Windows内核的访问检查实现逻辑、断点过滤规则共同导致的，核心原因有3个：

1. NtAccessCheck 是用户态系统调用入口，内核内部不会直接调用
   开放给用户态程序调用的NtAccessCheck是专门的系统调用接口，内核自身执行访问检查时（比如NtCreateFile流程中的权限校验），不会调用这个系统调用入口，而是直接调用底层内部实现函数nt!SeAccessCheck。你单步跟踪时看到的进入nt!NtAccessCheck大概率是符号解析的偏差，或者你进入的是该函数内部的公共实现段，并没有走函数入口点，所以在入口打的断点无法命中。
2. 进程过滤断点的上下文限制
   bp /p <eprocess地址> 断点仅对运行在目标进程用户态上下文的调用生效，而NtCreateFile中的访问检查完全运行在内核态上下文，部分场景下还可能被内核调度到系统线程上下文执行，进程过滤规则会直接过滤掉这些命中，导致断点无法触发。
3. 内核高频逻辑的性能优化
   访问检查是系统最高频的操作之一，Windows内核对其做了大量优化：部分场景下访问检查逻辑直接内联到NtCreateFile的执行流中，不会触发独立的函数调用；部分场景会走快路径跳过常规的函数入口校验逻辑，也会导致入口断点失效。

解决方案 #

你可以按以下步骤调整断点策略即可正常命中：

• 优先在内核访问检查的实际入口打进程过滤断点：bp /p <myprocessaddress> nt!SeAccessCheck，90%以上的内核态访问检查场景都会命中该断点
• 如果你需要进一步缩小范围，可以加线程过滤参数避免其他线程干扰：bp /p <myprocessaddress> /t <目标线程ethread地址> nt!SeAccessCheck
• 如果你要精准捕获本次NtCreateFile流程的访问检查，可以先在nt!NtCreateFile断点命中后，打一次性断点直接运行：bp /1 nt!SeAccessCheck，执行g命令后会直接命中当前流程的访问检查逻辑。

内容的提问来源于stack exchange，提问作者Benj