It's dropping by a few MB per second and I don't want to wait an hour. I then stopped capturing and cleared the capture but it is taking many minutes for the commit charge to come down. It claimed that it was displaying ~20 items out of 128,000 (the 128,000 from before I applied the filter) but the commit size went up to ~15 GB (and there were two procmon64.exe processes). Thanks! I deleted most of the settings (I just kept DbgHelpPath and SymbolPath because I am lazy and didn't want to reconfigure) and then started it and reconfigured my filtered capture with most events dropped. If necessary I can do some debugging on the machine that currently exhibits the problem. Actual behaviorįiltered events are not reliably dropped when requested, for unknown reasons. Expected behaviorįiltered events should be dropped when that is requested, thus reducing CPU and memory load. Otherwise you have to notice that the memory footprint is increasing without bounds. If you realize that the event counts are not supposed to go up when all events are dropped then the bug is obvious. It is not obvious that the feature is failing unless you know what to look for. The feature works sometimes and fails other times. Luckily it worked on one of my machines so I was able to gather the necessary data for them. This issue made procmon unusable for my coworker for this scenario.
On some machines the new version (3.52) failed, and on some machines the old version (3.52) worked. On one machine upgrading fixed the problem, but on other machines it did not. I was able to reproduce this on some other machines, but not all. Despite the request to drop all events the working set for procmon gradually increased to hundreds of GB. While trying to track down the cause of a file being created by Chromium's browser_tests my coworker left procmon running with an aggressive filter (so aggressive that no events were shown) and with Drop Filtered Events checked.
0 kommentar(er)
