Verify that both the source and target system have at least 500MB free.

Test to verify that the remote system responds to ping and that PowerShell can see procmon.exe and psexec.exe.

In my case, I ran the script under a domain admin account. Note: This script was only tested in my environment and assumes you have full permissions to the target system. Once that’s done, go to the last line of the script and change “remotecomputerhere” to the computer you wish to collect data from and specify the duration anywhere from 10 to 100 seconds. To run this script, I recommend opening it in the PowerShell ISE and editing the variables around line 34 to point to the path where you keep your psexec and procmon executables. Note that the script is hardcoded to limit you to a maximum of 100 seconds as I discovered the hard way that Procmon generates an enormous amount of data and you can easily fill the remote drive if you’re not careful. It accepts just two parameters, a -ComputerName for the name of the remote computer you wish to connect to and -Duration for how long procmon will run for on the remote system.

But there is a world of difference between an idea and a practical implementation and that’s what I have to share with you today.īelow is a PowerShell script that includes a function called Get-ProcMonData. I’m afraid I couldn’t find that blog post so I can’t give credit to the original author of the idea. My googling revealed a suggestion in some forum to use psexec to run procmon.exe on the remote machine and then copy over the PML file to your machine for analysis. I found myself in this exact situation yet again today and finally decided to sit down and solve it once and for all. Unfortunately you google this and discover that it’s not possible due to the amount of data that process monitor generates and can’t pass it all over the wire. You need ultimately to run Process Monitor remotely. However perhaps that computer is always in use and you simply can’t log in locally to launch resource monitor or process monitor. You need to figure out what exactly what processes and files are causing that disk IO. You are reviewing log files and discover that a remote computer (perhaps a virtual machine running on shared storage) is running wild and hammering on the disk. Have you ever been in the following situation?

I have finally solved something that has been a pain in my side for years now.

Remote process monitor windows