wj3*_*j32 40
(我是Process Hacker的作者.)
首先:
当程序访问映射到虚拟地址空间但未加载到物理内存中的页面时,页面错误是硬件引发的软件陷阱.
这并不完全正确,正如后面同一篇文章中所解释的(次要页面错误).存在软页面错误,所有内核需要做的是将页面添加到进程的工作集.这是Windows Internals书中的一个表(我排除了导致访问冲突的表):
- 故障原因 - 结果
- 访问未驻留在内存中但位于页面文件或映射文件中的磁盘上的页面 - 分配物理页面,并从磁盘读取所需页面并进入相关工作集
- 访问备用列表或已修改列表中的页面 - 将页面转换为相关的进程,会话或系统工作集
- 访问需求零页面 - 将零填充页面添加到相关工作集
- 写入写入时复制页面 - 制作进程私有(或会话私有)页面副本,并替换原始进程或系统工作集
如上所述,页面错误可能由于各种原因而发生.其中只有一个与从磁盘读取有关.如果您尝试从堆中分配一个块并且堆管理器分配新页面,然后访问这些页面,您将获得一个零需求页面错误.如果您尝试通过写入kernel32的页面来挂接kernel32中的函数,那么您将获得写入时复制错误,因为这些页面是以静默方式复制的,因此您的更改不会影响其他进程.
现在更具体地回答您的问题:Process Hacker在更新其服务信息时似乎只有页面错误 - 也就是说,当它调用EnumServicesStatusEx时,它会向SCM(services.exe)发送RPC.我的猜测是,在这个过程中,正在分配大量内存,导致需求为零的页面错误(服务信息需要几个页面来存储,IIRC).
- 为了完整起见，在操作系统术语中，除了次要（软）/主要（硬）之外，还有第三种页面错误：*无效*页面错误是当内核的页面错误处理程序决定该进程甚至不符合逻辑时映射该虚拟地址。例如，NULL 指针 deref - 虚拟地址 0 未映射到硬件页表中（因此 #PF x86 硬件异常），并且当内核检查如何纠正这种情况并重试错误指令时，它发现没有修复。（在 Linux 上，内核会传递 SIGSEGV 信号（段错误）或在没有处理程序的情况下终止进程。） (2认同)
缓慢但稳定的页面错误源是操作系统探测不常访问的页面.在这种情况下,操作系统会标记一些不存在的页面,但会将它们保留在内存中.如果应用程序访问该页面,则会发生#PF陷阱,操作系统只会再次标记该页面,而不会再进行任何操作.如果"长时间"过去并且页面从不跳过故障,则操作系统知道如果需要,页面是交换的良好候选者.即使在没有资源压力的情况下,该机制也可以主动运行.
| 归档时间： |
|
| 查看次数： |
54750 次 |
| 最近记录： |