如何在 Windows 上生成进程并查看它使用哪些文件？
我想在 Microsoft Windows 上编写一个 C++ 函数，它生成一个进程，除了进程的终止状态之外，还返回该进程读取或写入的所有文件的列表。它不应该需要衍生应用程序的任何合作。
例如，如果生成的程序是 Visual Studio C++ 编译器，则该函数将生成一个列表，其中包含编译器打开的源文件、它读取的所有头文件以及它创建的 .OBJ 文件。如果它还包含程序包含的诸如 .DLL 文件之类的内容，那就没问题了。但同样，无论生成什么程序，它都应该起作用；编译器只是一个例子。
一个转变：如果该进程创建子进程，我还需要监视它们的文件访问。
第二个转折：如果进程尝试打开一个文件，我希望能够让它等到我可以创建该文件，然后才让它恢复并打开该文件。 （我认为这排除了 ETW。）
我知道这听起来可能像是一些可怕的拼凑的成分。但如果我能做到这一点，最终的结果将会非常酷。
I would like to write a C++ function, on Microsoft Windows, that spawns a process and returns, in addition to the process's termination status, a list of all the files the process read or wrote. It should not require any cooperation from the spawned application.
For example, if the program spawned is the Visual Studio C++ compiler, the function would produce a list containing the source file the compiler opened, all header files it read, and the .OBJ file it created. If it also contained things like .DLL files the program contained, that would be fine. But again, it should work regardless of the program spawned; the compiler is just an example.
A twist: if the process creates subprocesses, I need to monitor their file accesses as well.
A second twist: if the process tries to open a file, I would like to be able to make it wait until I can create that file—and only then let it resume and open the file. (I think this rules out ETW.)
I know this probably sounds like an ingredient for some horrible kludge. But if I can get this working, the end result will be really cool.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您只需将自己放入 Hack City 并满足该要求- 你是对的，ETW 会是一个更容易的解决方案，但它也无法阻止文件调用。
基本上，您需要执行以下操作：
请记住，您将注入代码并对内存中的图像进行修复，该图像可能与您的位数不同（即您的应用程序是 64 位，但它正在启动 32 位进程），因此您将必须有 x86 和 amd64 版本的 shim 代码才能注入。我希望通过写这篇冗长的谩骂，您可以说服自己，这实际上是一个糟糕的想法，很难正确实现，并且挂钩 Win32 函数的人会让 Windows 操作系统开发人员感到悲伤。
You just put yourself into Hack City with that requirement - you're right that ETW would've been a far easier solution, but it also has no way to block the file call.
Basically, here's what you're going to have to do:
Keep in mind that you'll be injecting code and making fixups to an in-memory image that may be a different bitness than yours (i.e. your app is 64-bit, but it's starting a 32-bit process), so you'll have to have both x86 and amd64 versions of your shim code to inject. I hope by writing this lengthy diatribe you have convinced yourself that this is actually an awful idea that is very difficult to get right and that people who hook Win32 functions make Windows OS developers sad.