david-risney
commented
4 months ago - https://github.com/Walkman100/FileLocks/blob/master/GetAllHandles.cs - doesn't appear to handle the hang issue
- https://github.com/sunneo/utilities/blob/7ef0881916be8ca50124813bfa845b6f494b183f/FileLockInfo.cs#L317 - notes the hang issue but doesn't appear to workaround the issue
- https://github.com/nil-ref/Code/blob/4d8a81b78b92bafe317ca9c40b5bdd081cc36c24/%E4%BB%BB%E5%8A%A1%E7%AE%A1%E7%90%86%E5%99%A8/Get%20all%20handles%20of%20a%20process/Program.cs#L13 - this one may be running the handle lookup code on a separate thread and killing it if it hangs. But doesn't attempt to finish beyond the hang afaict.
- https://github.com/khellang/pretzel/blob/01108237a0f21fc36d73e9fd069e6bcc9e7f97cf/src/Pretzel.Logic/SanityCheck.cs#L284 - this one too
- https://github.com/OleksandrKulchytskyi/HandlesExplorer/blob/master/HandlesExplorer/Services/DetectOpenFiles.cs - appears to handle hang issue with ThreadPool.QueueUserWorkItem per name query which might be a bit heavy for every name.
- https://github.com/microsoft/PowerToys/blob/main/src/modules/FileLocksmith/FileLocksmithLibInterop/NtdllExtensions.cpp - looks like it is running the whole deal on another thread and monitoring it. If it hangs it terminates it and starts a new child thread to run on the rest of the handles. This is probably a better approach than above. If it was written in C# that would be better
Consider looking into OSS that uses NtQuery* related OS functions to find which processes have which pipes open. Issues previously were that it could be slow and that it can randomly hang when getting the name of some pipes. Running with threads we terminate on timeout could mitigate the hangs and could help with the perf. Adding multithreading complicated the code but perhaps OSS code already does this that we might use.