从远程共享进行分页
假设我有一个在 Windows XP 上运行的应用程序，该应用程序是从映射的网络驱动器“启动”的。 当执行此应用程序触发页面错误并且需要从磁盘读取代码页时，假设它不在页面文件中，Windows 是否会前往映射的网络共享以从磁盘读取必要的代码页，或者将它在第一次执行时会在本地复制一份吗？ 我意识到存在不同类型的页面错误，但我特别询问必须从磁盘上的文件读取代码的情况。 在这种情况下，由于应用程序的映像存在于远程共享上，我假设页面错误处理程序必须转到网络共享来检索代码页。 它是否正确？
我有一个以这种方式运行的应用程序，它似乎定期“挂起”系统，但系统会在短时间内（有时仅几秒钟，有时 10-15 分钟）后变得响应。 该系统还安装了许多 A/V 和 DLP 产品，因此还安装了多个 TDI 筛选器驱动程序和文件系统筛选器驱动程序，这些驱动程序似乎会增加处理页面错误的延迟，尤其是在必须从进程调入代码的情况下存在于远程共享上的图像。
我一直在阅读Windows Internals，它讨论了页面错误处理，但在处理远程映射驱动器时我没有看到任何提及这种情况的内容。 我假设它必须进入网络共享来检索必要的代码页，但我只是想确保我是对的。 如果有人有任何其他推荐读物，我很想听听。 我目前已经在有问题的系统上附加了一个内核调试器，这样我就可以实时捕获它，但是，当然，由于我已经附加了内核调试器并且它已经运行了 2 天，所以我还没有看到问题再次发生。
Let's say that I have an application running on Windows XP that is "launched" from a mapped network drive. When a page fault is triggered by the execution of this application and a code page needs to be read from disk, assuming it's not in the pagefile, will Windows go out to the mapped network share to read the necessary code page in from disk or will it make a copy of it locally when it's first executed? I realize there are different types of page faults but I'm specifically asking about the case where the code must be read from the file on disk. In this case, since the application's image exists on a remote share I'm assuming the page fault handler must go out to the network share to retrieve the code page. Is this correct?
I have an application that's running in this manner and periodically it seems to "hang" the system but the system becomes responsive after a short period of time, sometimes just a few seconds and in other cases 10-15 minutes. This system also has a lot of A/V and DLP products installed on it and thus several TDI filter drivers and file system filter drivers which seemingly would add to the latency in processing the page fault especially if the code must be paged in from a process image that exists on a remote share.
I've been reading through Windows Internals and it discusses page fault handling but I don't see any mention of the case when dealing with a remote mapped drive. I'm assuming it's got to go out to the network share to retrieve the necessary code page but I just want to be sure I'm right. If anyone has any other recommended reading I'd love to hear it. I've currently got a kernel debugger attached to a problematic system so I can catch it in the act but, of course, since I've attached the kernel debugger and have had it running for 2 days I've yet to see the problem occur again.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定这个问题是否正确。
所有代码都必须在本地内存中才能执行。网络映射驱动器上的页面错误将导致网络 I/O 获取适当的页面，这将是加载到本地内存中然后使用。
是的。页面错误处理程序不知道驱动器是网络映射的。它将发出文件系统 IRP。网络映射驱动程序将拦截该信息并将其转换为网络 IRP。因此页面错误处理程序是只是做正常的事情；它不知道你在后台做巫术。
嗯，有了这么多内核黑客攻击的东西，我的第一个想法是你的 Windows 安装只是被破坏了。 A/V 的东西对 Windows 来说是毒药，你似乎有大量的东西被塞进了内核 - 你是在自找麻烦，而且似乎麻烦已经来了。
最有可能的是最简单的解释； 考虑到这里存在的恶意软件数量，Windows 很可能只是被破坏了。 您不需要更深入的技术解释！
I'm not sure the question is correct.
All code must be in local memory to be executed. A page fault on a network mapped drive will cause network I/O to fetch the appropriate page, which will be loaded into local memory and then used.
Ye-e-e-s-s-s. The page fault handler doesn't know the drive is network mapped. It will issue a file system IRP. The network mapping driver will intercept that and convert it into a network IRP. So the page fault handler is just doing its normal thing; it doesn't know you're doing voodoo in the background.
Erm, with that much kernel hacking stuff on it my first thought is that your Windows installation is simply shagged. A/V stuff is poison to Windows and you seem to have a ton of stuff jacked into the kernel - you are asking for trouble, and it seems trouble has come calling.
Simplest explanations are most likely; given the amount of badware you have here, it's most likely Windows is just shagged. You don't need a deeper technical explanation!