我运行xperf以便在运行时获取程序的跟踪信息。该程序读取一个文件。它是用F＃编写的.NET程序，文件在这里阅读：
System.IO.File.ReadAllLines("MyReadFile.txt")
好。我运行xperf：
xperf -on DiagEasy
我停止xperf并合并到一个文件中：
xperf -d myfile.etl
行。
现在我写道：
xperf -i myfile.etl -o myfile_stat.txt -a diskio -detail
我这样做，所以我可以获得一个包含所有文件信息的文件。显示的文件是一个格式化的文本文件，以便让我按文件查看磁盘统计信息。在跟踪会话期间操作的每个文件都显示有关于读取/写入文件的过程的大量数据等等...
但MyReadFile.txt不会出现在那里。
为什么????? 是因为cpu采样频率太低了？我怎样才能改变它？...
然而，我的程序读取文件，我敢肯定，程序启动并打印出内容......
由于
答案 0 :(得分：2)
DiagEasy打开IO进出磁盘的ETW工具。如果文件已经在内存中，那么就没有IO。您需要打开上面Gary所描述的FILE_IO和FILE_IO_INIT事件来捕获所有文件访问，甚至是当前在内存中的文件。
你可能会问为什么文件在内存中。收集数据时，文件可以通过两种方式存储在内存中。
自从您启动系统后，您已经访问过该文件，无论是阅读它还是编写它。该文件将保留在内存中，直到有足够的内存需求将这些文件页从RAM中推出。由于这些是文件支持的页面，因此任何已修改的页面将在页面被编写之前写入文件（MyReadFile.txt），然后提供给进程以供使用。
文件在内存中的第二种方式是SuperFetch看到对该文件的重复访问，并在磁盘空闲时主动将其加载到内存中。这样做是为了消除从磁盘读取数据时对文件的延迟访问。
答案 1 :(得分：1)
文件I / O监控不基于采样。相反，相关的ETW提供程序会为每个受监视的I / O引发事件。它不应该错过任何东西。
如果这是我的代码，我怀疑它没有真正读取该文件。 ERROR_FILE_NOT_FOUND，也许？
此外，该标志应该是DiagEasy，而不是EasyDiag。
FWIW，这是我如何进行文件监控，启用堆栈跟踪：
xperf -on PROC_THREAD + LOADER + FILE_IO + FILE_IO_INIT + FILENAME -stackwalk FileCreate + FileRead + FileWrite + FileFlush + FileQueryInformation + FileSetinformation + FileDelete
此致 加里