I have Windows 10 Pro 64 bit, and believe there is a bug with Process Monitor Portable 3.33. This is a new, standalone installation (I am not using the Portable Apps Platform).
It concerns the "File system activity" component only; everything else seems to work fine. When running ProcMonPortable for the first time, things behave as expected. But if ProcMonPortable is closed and restarted, no file activity is recorded whatsoever, even if all filters are reset (or deleted!).
I first tried deleting my settings folder, and then deleting ProcMonPortable completely and reinstalling it. Neither worked.
What did work temporarily was rebooting my PC. File activity was recorded fine until ProcMonPortable was closed and restarted, at which point the bug returned just as before.
Any ideas?
Bluto
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Have you tried launching
Procmon.exedirectly?If you still see the issue when launching
Procmon.exedirectly, then the issue is with Process Monitor.Please let us know if you continue to see the same issue when running
Procmon.exedirectly. It can be found in theApp\ProcessMonitorfolder.~3D1T0R
Thanks for the reply. Quick question before I try your suggestion: will launching the "ProcMon.exe" file directly make it run in a non-portable way? i.e. Will this put keys in the registry and settings in various hidden folders, rather than in the portable installation folder?
Bluto
It will run exactly the same as the 'local' (non-PortableApps.com) release of Process Monitor, which leaves traces in the registry.
~3D1T0R
I thought the original (non-portable) ProcMon worked fine, but was mistaken: I had a slightly earlier version than 3.33 in mind. Having run ProcMon.exe directly as you suggest, I can see the same bug appearing.
Thus the bug has nothing to do with PortableProcMon - apologies for flagging it up as such. I'll let the people at Sysinternals know.
Thanks again for your help.
Bluto
If you're worried about what was left behind when you ran Process Monitor Portable in a non-portable way, you should be able to force the launcher to clean it up by adding an empty text file in the
Datafolder calledPortableApps.comLauncherRuntimeData-ProcessMonitorPortable.ini, and runningProcessMonitorPortable.exe.~3D1T0R
Thanks for this. As it happens, ProcMon.exe doesn't make too many registry entries (about 4 or 5) and I was able to remove them in regedit.
Does this tip (changing the filename accordingly) work for all apps from PortableApps.com?
Bluto
This isn't changing a filename, but adding a file instead.
There is a system built into the PortableApps.com Launcher (PAL) which detects when the app was unable to clean up after itself and forces a clean-up the next time you try to start the app. It does this by creating that file, with some specific contents that tells it where the launcher's temp directory is when it starts, then removing it when it cleans up after the base app has closed.
Seeing as you've run the base app without the launcher, there's no need for the text that tells it where its temp directory was, so a blank file with the appropriate name will cause it to sufficiently clean up after itself.
Note: (IMPORTANT) This will replace any data in your Data folder with the data currently on the machine, so if you're trying to clean up after having run the app directly, but you want to use the data you already have in your Data folder, you should temporarily rename the existing Data folder, and create a new one containing the file which causes cleanup, after which you can delete that Data folder and rename your original one back to "Data".
Note2: There several apps which do not use PAL, so this trick won't work on them, and there are a number of apps which are able to run fully portably (either because the app is already truly portable, or by placing a file, running with specific arguments or starting with specific configurations in place) and thus don't need PAL to clean up after them, making this trick pointless.
Note3: (VERY IMPORTANT) Don't do this if you have a local version of the app installed, as it'll effectively steal the local configuration and stick it in your Data directory to be used by the Portable App.
~3D1T0R
Thank you so much for taking the time to write such a detailed and useful post. I think I've just about understood it!
Agreed about adding a file rather than changing an existing filename - I didn't explain myself clearly. I meant changing the filename of *your* example accordingly. e.g. Presumably TCPView could be fixed by creating "PortableApps.comLauncherRuntimeData-TCPViewPortable.ini".
I tested your procedure after running ProcMon.exe directly, and sure enough it removed the 4 or 5 registry entries automatically without my having to seek them out.
If I hear back from Sysinternals, I'll post an update here to let you know that ProcMon.exe has been fixed and is ready for a new portable version.
Bluto
Yes, the file name reflects the launcher it's for.
~3D1T0R
Out of interest, are you able to get either ProcMon or ProcMonPortable to work reliably on your PC? Unfortunately, I've heard nothing back from anyone at the sysinternals forum in nearly a week.
To reproduce the issue:
1) Run ProcMonPortable and test each of the 5 filters on/off. They appear to behave fine.
2) Close down the program and restart it.
3) Four of the five filters now work ok, but the "File system activity" filter does not show any file activity whatsoever, whether turned on or off. Saving all activity (including offscreen) to a CSV file demonstrates (on my PC at least) that ProcMon wasn't actually capturing any file activity.
4) Rebooting the PC allows you to go back to 1.
Bluto
Hello again, 3D1T0R.
I have now realised that the bug is, in fact, only present in ProcMonPortable.
It appeared to affect ProcMon as well, but that was only because I tried running ProcMon *after* the bug had manifested itself with ProcMonPortable.
In summary:
A) Running ProcMon after a reboot works fine. You can close ProcMon and run it again as often as you like - no problem.
B) Running ProcMonPortable after a reboot works fine the first time only. If you close it and then try running either ProcMonPortable or ProcMon, then file system activity is neither captured nor displayed on screen, whatever you do with the filters. The only way to get it to work again is to reboot the PC.
Hope this makes sense and allows someone to track down what is causing this bug. I'd be intrigued to know what is going on behind the scenes for a reboot to allow it to work again, albeit only once more!
Bluto
I'm able to run Process Monitor Portable multiple times on both my main Windows 10 machine and a clean Windows 7 virtual machine without issue.
Sometimes, the impossible can become possible, if you're awesome!
Thanks for the feedback. My system is Windows 10 64-bit, version 1703, build 15063.540
It is a pretty new reinstallation of Windows (about 2 weeks old now), and the only other software installed is:
* Avast Free Antivirus
* Microsoft Office 365 ProPlus (version 2016 for Office Apps)
* Foobar2000 (Portable installation of small music player)
I have ProcMonPortable installed in C:\Portable\ProcMonPortable.
I tried disabling the Avast shields while experimenting, but this didn't help. Even deleting the ProcMonPortable folder and reinstalling it doesn't work (until I reboot the PC...).
Given the above, the only thing I can think of is that ProcMonPortable perhaps leaves some process running in the background on my system after being closed? This process may then prevent ProcMon / ProcMonPortable from working when the program is launched again. But when the PC reboots, maybe this process dies so all is well again. This is pure speculation on my part.
I examined the processes with ProcExpPortable, but it's like looking for a needle in a haystack. There are, however, no obvious ProcMon processes still running in the background once it is closed.
Bluto
Do you have either of these registry keys on your system?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{3A1380F4-708F-49DE-B2EF-04D25EB009D5} HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_PROCMON23If so, try deleting them and rebooting. ProcMon uses those in a kind of odd way.
Sometimes, the impossible can become possible, if you're awesome!
No, neither of those keys are there whether ProcMonPortable is running or not.
Bluto
Hello again, I am able to reproduce this on Windows 10 64-bit Version 1703 Build 15063.540, and can confirm that repeated executions of Procmon.exe do not trigger the issue, however running ProcessMonitorPortable.exe once, which results in a fully functional Procmon.exe process, triggers the issue for all subsequent executions of either Procmon.exe or ProcessMonitorPortable.exe.
I have yet to see what the actual cause is, but will investigate further.
~3D1T0R
Hello,
Just noticed version 3.40 tonight. For info, the previous issue persists when using this new version.
Bluto
It appears due to the fact that we need to invoke AccessControl on two keys used by the app. Otherwise these keys are undeleteable. Without doing this, the keys remain behind but the app can be run multiple times with file monitoring working.
So, leave two HKLM registry keys behind and have the app not be properly portable but able to use file monitor on more than one run per reboot or remove the keys and have it be properly portable but not able to use file monitoring on the second run?
Sometimes, the impossible can become possible, if you're awesome!
Ah - so that's why it happens. Thank you for taking the trouble to explain this.
The reason I always use portable apps where possible isn't really to do with privacy as such, but more due to the fact that I like to tinker with settings. Being able to return to default settings easily is just so handy.
Overall, my preference would be for your second option: to leave it as is, i.e. properly portable, but only fully useable once per reboot.
Bluto
Would this be a valid, real-world use case for the ExecAsUser code suggested here?
Launcher would have admin privileges to delete those keys while the app would only be run as a user.
(Note that I haven't looked into it deep enough to say yes or no it would work, I am just making a suggestion based on a quick read-through of this problem and what I understood to be the idea behind that code)
The app itself can't monitor file activity without admin rights. Windows itself interprets the driver/service as needing above admin rights for those keys.
Sometimes, the impossible can become possible, if you're awesome!