Using Powershell as a backup for handle.exe is not a good solution.

[lukebakken]

Describe the bug

We have had a couple Windows users report excessive CPU use of Powershell when it is used to calculate the number of handles being used by RabbitMQ. This was introduced by #6614 as a fix to #6613.

• https://stackoverflow.com/questions/76575596/rabbitmq-continually-spawns-powershell-which-results-in-100-cpu-usage
• https://groups.google.com/g/rabbitmq-users/c/hYOCHG1aCss
• https://github.com/rabbitmq/rabbitmq-server/discussions/8541

We know that handle.exe sometimes does not return valid information, and of course sometimes is not installed. On Windows, keeping track of used handles (file descriptors) is not as critical as on Linux. Perhaps the best solution is to remove the Powershell backup.

Reproduction steps

Run RabbitMQ on Windows without installing handle.exe.

Expected behavior

No high CPU usage no matter how we calculate handle usage.

Additional context

N/A

[michaelklishin]

One day we hope to add Windows support to https://github.com/michaelklishin/fshc, and use that as one more option, this time around, an open source one.

https://github.com/michaelklishin/fshc/issues/1

[lukebakken]

@michaelklishin I just had a thought... On Windows, OTP ships with a standalone exe called win32sysinfo.exe. We already use it to get information about free disk space. We should consider opening a PR for it to return grouped handle information for a specific process, the same way handle.exe does. I'll investigate.

[lukebakken]

Note: wmic.exe might be an acceptable alternative. I will do some testing.

[lukebakken]

Here is a project with exactly the code we need to replace handle.exe:

https://github.com/Softanics/EnumWinHandles

The "problem" with that code (and presumable with handle.exe), is that on every call, all processes in the system are enumerated for information. Then you must compared the process ID with the one you're interested in to narrow the results down, at which point you can then figure out what each type of handle is being used.

In our case, it might be better to just use GetProcessHandleCount

[michaelklishin]

One day we hope to add Windows support to https://github.com/michaelklishin/fshc, and use that as one more option, this time around, an open source one.

rabbitmq/fshc#1

fshc now has Windows support thanks to @the-mikedavis, so we will take another swing at providing a handle.exe alternative quite soon.

[c0shea]

Note: wmic.exe might be an acceptable alternative. I will do some testing.

We have various infrastructure monitoring tools in place that use WMI to query various system info and it has the same issue where it sometimes spikes the CPU to 100%. Seems like the fshc alternative may work better than this.

[geggleau]

One day we hope to add Windows support to https://github.com/michaelklishin/fshc, and use that as one more option, this time around, an open source one. rabbitmq/fshc#1

fshc now has Windows support thanks to @the-mikedavis, so we will take another swing at providing a handle.exe alternative quite soon.

We have observed "handle.exe" loading the "procexp.sys" driver when it runs, which triggers some AV/EDR systems. Definitely have my vote to switch as this would fix this issue!

[michaelklishin]

fshc needs to produce its first release, then we can switch. It's a matter of setting up release automation for a Rust project on GitHub actions, at a minimum.