问题标签 [procmon]

首先，我必须提供一些上下文。

我可以通过在键 'HKLM\SYSTEM\CurrentControlSet\Services\PROCMON24\Instances\Process Monitor 24 Instance' 中进行两项更改来将 procmon 设置为在某个非默认高度运行：

1. 将海拔高度值从其默认的“385200”更改为所需的值；例如。'136500'
2. 并为密钥添加特殊权限： user:Everyone type:Deny permissions:('set value' | 'delete')

改变海拔高度的原因是显而易见的。添加特殊权限的原因不太明显：没有此 procmon 将简单地将 Altitude 重置为其默认值。

好的，这是我的问题：

我无法以编程方式删除添加的权限或更改该键或其值。这并不奇怪，因为权限拒绝“每个人”访问。

但是，我可以使用 regedit 轻松删除该权限。我只是选择权限并将其删除。

那么 regedit 使用什么技巧来覆盖该权限呢？

我可以看到它以当前用户身份运行，而不是“系统”。我可以使用 psexec 以“SYSTEM”身份运行删除脚本，但这也被拒绝访问。

我们的 VSTO 插件有一个非常奇怪的问题。

在我们的加载项中有标签控件，它们从 app.config 文件中读取标签文本值并将配置文件中的文本显示给用户：

我们最近更新了 app.config 文件，为我们在日本的最终用户将英文显示信息替换为 Kanjii。

当我们重建 MSI 并安装在我们的测试机器上时，插件没有显示 Kanjii（尽管它在开发中正确显示）。

现在我们想知道安装目录中的配置文件是否正在被读取，或者信息是否被缓存，或者加载项是否正在从某个地方的另一个文件中读取。

更奇怪的是，我们更改了 app.config 文件中用于代码逻辑的其他值，而且这些值似乎可以正常加载。

我们目前正在使用 Procmon 来找出配置文件的加载方式，但是，同时过滤以下内容：

• 进程名称包含 Outlook
• 路径包含“OurOutlookPlugInName”

这会产生超过 400 个结果，但除非我在 Visual Studio 中调试代码，否则我们看不到配置文件的任何文件处理。

在我们的安装机器上，我们还从安装目录中删除了配置文件，认为这可能是插件是否正在从安装目录中读取配置文件的线索，但它没有效果，并且加载了插件通常再次显示英文而不是汉字。

所有配置设置都在应用程序级别。

有没有办法让我们知道我们的插件从哪里加载我们的配置文件？

我们是否在我们的 MSI 构建中做了一些不正确的事情，导致更新的配置文件无法加载？

更新：

我使用 Telerik JustDecompile 打开了 C:\Program Files (x86)\OurVSTOAddIn 安装目录中的 dll 文件，以查看配置设置是否写在 dll 中的某处，我可以看到在 OurVSTOAddIn->My Settings 下肯定有 DefaultSettingValues ， 如下所示：

这是有道理的，因为这些是应用程序范围设置，这将阻止用户更改配置设置。

但我在想，如果我们使用应用程序范围变量，每次我们都需要重建 msi 以进行发布，这对我来说没有意义，因为我们想要为项目使用配置设置的原因是不需要重建配置更改。

我正在 Windows 10 中构建 Haskell 命令行应用程序，并试图通过跟踪系统调用并查看哪些失败来调试有关 Windows 260 字符文件路径限制的问题。

我为此使用了 procmon ( https://docs.microsoft.com/en-us/sysinternals/downloads/procmon )，这看起来很不错，但是虽然它显示了许多相关的日志条目，但我很惊讶地发现它不显示实际超过 260 个字符并导致我的应用程序崩溃的特定 CreateFileW 调用的条目。

我短暂地尝试过 Win32 API Monitor ( https://www.apimonitor.com )，但无法做出正面或反面；它似乎更适合附加到已经运行的 GUI 应用程序而不是需要在特定目录中启动的命令行应用程序等。

有没有比这些更好的选择，或者更好的方法？

这是我的问题，我需要比较两个转换为 CSV 文件的 procmon 扫描。

这两个文件具有相同的列名，但显然内容不同。如果有相应的匹配项，我需要检查从第一个文件到第二个文件的“路径”（第 5 列），并将第二个文件的整行打印到第三个 CSV 中。

我已经用谷歌搜索了很长一段时间，似乎无法让它像我想要的那样工作，感谢任何帮助！

我尝试了许多在线工具和其他 python 脚本，但无济于事。

我需要诊断无法达到最佳性能的服务器。CPU 使用率在大约 500 毫秒内降至零，然后在尝试处理排队的请求时飙升至 100%，这种模式在几个小时内重复，之后操作再次变得平滑（操作多年来一直很平滑）

这向我表明，工作线程在等待外部事件发生时处于空闲状态。该应用程序很复杂，我们无法查明罪魁祸首。

可以将进程监视器配置为每次线程休眠等待某个事件时记录吗？ 如果可能，该事件是否与特定的堆栈跟踪相关？

如果上述情况可行，也许我可以将 CPU 下降与等待事件相关联并找出罪魁祸首。

我之前已经成功地使用 Windbg 来诊断这类问题，但是在这种情况下，等待非常短暂，我不确定我是否可以在处理器空闲时让调试器完全中断。

我们正在对应用程序进行压力测试，并注意到一个奇怪的案例，即 Windows 内核接管了压力测试的执行。压力测试下的应用程序使用类似于这个passthrough 驱动程序的minifilter 驱动程序获取系统范围的 IO 事件，主要是文件的 CRUD 。

在一个特定 VM 上使用spddisk进行压力测试期间（Windows Server 2019 1809 17763.864，未安装外部 AV 或其他安全软件），我们注意到System具有保留 pid 的进程4正在“接管”压力负载执行。一个简单的批处理脚本似乎也发生了同样的情况（循环创建、读取、删除文件）。我从未在任何其他系统上看到过这样的事情，我们无法在其他任何地方重现这种行为，只能在该单个 VM 上。

“接管”发生在执行压力测试几秒钟后，并以下列方式表现出来：

• 进程 id 更改为系统保留 pid 4
• 线程 id 更改为另一个tid
• 用户 SID 从 更改S-1-5-21-2874696658-2485333267-3621126573-500为S-1-5-18
• 用户从更改win-saacuiping\administrator为NT AUTHORITY\SYSTEM

我们已经在procmon中捕捉到了这一点

这感觉像是某种沙盒，但我以前从未真正见过这种情况。用于压力测试的简化命令是这样的

谁能解释一下，为什么执行突然从一个进程传递到 Windows 内核系统 4？

我正在使用Sysinternals Process Monitor来调试一些传入事件，现在我正在尝试在 Path 上创建一个过滤器并使用通配符。我试图使用的是过滤以 c:\MyApp\MyDocuments\Temp 开头并以 .pdf 结尾的路径

路径过滤器应如下所示：c:\MyApp\MyDocuments\Temp*.pdf

我怎样才能做到这一点？

我正在使用Sysinternals Process Monitor来调试一些传入事件。现在我正在尝试在“时间”上创建一个过滤器，以过滤那些时间大于特定时间的传入事件。

例如，如果我想获取那些时间大于 '13:30' 的传入事件，我该怎么做？

我在 VM 上运行一些测试时使用 procmon 来保存日志。我正在使用 python 和 pytest，但我认为这里无关紧要。对于我正在运行的每个测试以启动 procmon：

如果测试失败，我将终止 procmon：

然后我正在保存虚拟机的快照。为了打开 logs.pml 以使其可读，我在进入 VM 的快照后运行：

但有时我会收到错误：

虚拟机中的错误图片

1. 为什么我会收到此错误？我可以看到 procmon 运行然后被我的代码终止（我可以进入 VM 并看到测试正在运行，执行 procmon 并终止它）。
2. 我该如何解决这个问题？注意：它有时会发生，大多数时候它会为我创建日志作为可读的 PML 文件。

我们在运行 Windows 10 的 VMware 主机上运行 Docker。

根据第一条评论，我想知道问题是否不是特别是读取部分，但也许在加载结束时发生了一些事情，阻止了这个 exe 被缓存在内存中。