ADExplorer v1.51, Autoruns v14.07, CacheSet v1.02, Process Monitor v3.87 and Sysmon v13.31

Hello Alex_Mihaiuc , thank you for responding, and sorry for the delay with the reply, for some reason I did not get the notification, may be I accidentally turned it off.

I would like to clarify that any filter does not load, just go to filters, reset filter, add an arbitrary rule, save, and once you exited the Process Monitor and re-started it again try loading that filter. It does not. I just quickly did the above steps, and create a rule to filter: "Path contains google then include". The filter iteself works, but when saved it is not possible to load it. The file that was produced was called "Filter 0.PMF" and you can rund the following PowerShell command to produce it:

[Convert]::FromBase64String("swMAAAEYAAAAh5wAAAYAAAABDgAAAGcAbwBvAGcAbABlAAAAAAAAAAAAAAB1nAAAAAAAAAAYAAAAUAByAG8AYwBtAG8AbgAuAGUAeABlAAAAAAAAAAAAAAB1nAAAAAAAAAAYAAAAUAByAG8AYwBlAHgAcAAuAGUAeABlAAAAAAAAAAAAAAB1nAAAAAAAAAAaAAAAQQB1AHQAbwByAHUAbgBzAC4AZQB4AGUAAAAAAAAAAAAAAHWcAAAAAAAAABwAAABQAHIAbwBjAG0AbwBuADYANAAuAGUAeABlAAAAAAAAAAAAAAB1nAAAAAAAAAAcAAAAUAByAG8AYwBlAHgAcAA2ADQALgBlAHgAZQAAAAAAAAAAAAAAdZwAAAAAAAAADgAAAFMAeQBzAHQAZQBtAAAAAAAAAAAAAAB3nAAABAAAAAAQAAAASQBSAFAAXwBNAEoAXwAAAAAAAAAAAAAAd5wAAAQAAAAAEAAAAEYAQQBTAFQASQBPAF8AAAAAAAAAAAAAAHicAAAEAAAAABAAAABGAEEAUwBUACAASQBPAAAAAAAAAAAAAACHnAAABQAAAAAaAAAAcABhAGcAZQBmAGkAbABlAC4AcwB5AHMAAAAAAAAAAAAAAIecAAAFAAAAAAoAAAAkAE0AZgB0AAAAAAAAAAAAAACHnAAABQAAAAASAAAAJABNAGYAdABNAGkAcgByAAAAAAAAAAAAAACHnAAABQAAAAASAAAAJABMAG8AZwBGAGkAbABlAAAAAAAAAAAAAACHnAAABQAAAAAQAAAAJABWAG8AbAB1AG0AZQAAAAAAAAAAAAAAh5wAAAUAAAAAEgAAACQAQQB0AHQAcgBEAGUAZgAAAAAAAAAAAAAAh5wAAAUAAAAADAAAACQAUgBvAG8AdAAAAAAAAAAAAAAAh5wAAAUAAAAAEAAAACQAQgBpAHQAbQBhAHAAAAAAAAAAAAAAAIecAAAFAAAAAAwAAAAkAEIAbwBvAHQAAAAAAAAAAAAAAIecAAAFAAAAABIAAAAkAEIAYQBkAEMAbAB1AHMAAAAAAAAAAAAAAIecAAAFAAAAABAAAAAkAFMAZQBjAHUAcgBlAAAAAAAAAAAAAACHnAAABQAAAAAQAAAAJABVAHAAQwBhAHMAZQAAAAAAAAAAAAAAh5wAAAYAAAAAEAAAACQARQB4AHQAZQBuAGQAAAAAAAAAAAAAAJKcAAAAAAAAABQAAABQAHIAbwBmAGkAbABpAG4AZwAAAAAAAAAAAAAA") | Set-Content "Filter 0.PMF" -AsByteStream

Here I encoded my file as base64 so I could post it for you here.

Once again, many thanks for looking into this, really appreciated.

Andrew Savinykh 

Process Monitor v3.87 unable to load driver on Windows 7.

Process Monitor v3.86 works! Please fix.

Hi andrewsav , could you upload such a malfunctioning filter file somewhere? Also please describe the specific criteria used for the filtering (steps taken, filters). Just email to "syssite", I'll be able to check it.

The filter loading bug was reported as early as early June https://docs.microsoft.com/en-us/answers/questions/423114/cannot-load-filter-in-381.html

---

Alex_Mihaiuc wrote:

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

This Process Monitor update fixes a series of bugs with filter file loading, ring buffer handling and improves filter dialog navigation, some UI interactions with column headers and the About dialog.

---

I still cannot load a filter in v 3.87, even a new filter. Since the post over at https://docs.microsoft.com/en-us/answers/topics/windows-sysinternals-procmon.html just get ignored, I was wondering what is the correct way to engage with the team and get this finally fixed, e.g. provide more details that would help the team to find and address the bug? Thank you in advance.

(Somehow my logon is now making me a "New Contributor." I'm the same old Aaron Margosis, though.)

rpodric - As Alex_Mihaiuc says, when you run the 32-bit version, the tool will extract and run a 64-bit version if native 64-bit code is required to do the job. It usually extracts to the caller's temp directory. The *64.exe executables can be useful on systems that don't have WOW64, and on systems where execution from temp directories is disallowed.

Autoruns 14.07 is still broken in my case.

I tried the new version on Windows 10 LSTB latest build (14393.4825) and still get an error trying a open/compare with a freshly saved .arn file.  It's been like this since v14.0 Either someone is unable to test this or they cannot recreate the error. The old v13 format works fine. By testing, I mean on systems that are still supported, like W7 ESU, or Win 8.1 or W10 LTSB. Those are currently what I use. Here's a LOL quote I got about  this bug reported previously: "really weird it's regressing on the older systems, I'll have a look and get back to you with a fix."

Send me a debug version with instructions. I'm willing to help.

I ran another test in a VM with an LSTB system and saving and opening the .arn file works fine there. If I use the same file on my local LTSB, it loads there too. So for some reason saving an .arn file on my local LTSB cannot be loaded. It doesn't load in the working VM either. Autoruns is creating an invalid .arn when run locally here. Any ideas?

Hey Brian,

With Autoruns they both work regardless of system bitness. For other tools (like Process Explorer or Sysmon) the 32 bit version is almost twice the size of the 64 bit version because it actually contains the respective binary executable as a resource which gets unpacked and started on the fly.

The mention of "32/64 bit redirection" prompts me to ask about the exes that have "64" in the name.

I know the "a" ones are ARM, but speaking for Intel 64-bit systems (the vast majority of the population), is there really a point to running, say, Autoruns64.exe over Autoruns.exe? I've always just used the latter, which I assume is the 32-bit version, which of course still works on a 64-bit system. One or two of these tools might actually benefit from 64-bit (e.g. Process Monitor), but surely Autoruns is not one.

The answer may lie in whatever the redirection above is implying.