How to diagnose memory leaks and inexplicable client-side (Windows 10/Powershell 5.1) behavior across multiple invocations

Avineshwar (Gartner) 1 Reputation point


We have a fairly huge (~5k LOC) client-side PowerShell script to handle a very specific use-case (which is being realized due to the presence of the PS runtime offered by an enterprise software). That enterprise software ensures whenever an application starts, we can intercept that and arbitrarily evaluate (using our PowerShell code) and then either allow or block the start of an application. That PS runtime offers certain cmdlets which is fairly heavily utilized within the script, however, the PS environment comes primed with it. I am assuming that happens every time an "applicable" binary starts, so, there it would be leading to some level of impact. Essentially, we do not load those modules (where the cmdlets come from) within the code. That said, we do load some modules/types to ensure the script can function.

Generally, everything works well i.e. script starts and follows an expected flow and returns/exits properly. To cover our basis, we thought doing a GC at start and before ending might help, so, we do that. We also track any on-script-start variables and remove them before exiting/returning. We thought this might also help us in case we are missing any clean-up we might be missing within the code that may be affecting parallel invocation of this workflow (i.e. when an application that would trigger the script starts on Windows machine; there could be many such applications running in parallel but generally there should be just one such application at any given time). We ensure, unless missed somewhere, to not forget using the "Using pattern" or "Close/Dispose" method(s) to help our case of dangling objects and so on. Now, occasionally (and from there on until a system restart happens) the code gets stuck at a place (it is a background job started using "Runspace", not "RunspacePool"). We know it is in a stuck/infinite (or for all practical purposes) wait since at that place, there is a UI (ever-moving infinite progress dialog) component (offered via preloaded cmdlet). Based on our logs, it looks like the background job somehow does not finishes and therefore, that stuck behavior makes sense. In reality, it does not seem to be the case since that background job talks to an API that just appears to be responding fine as per the logs (and external perf testing).

So, what are some of the things that could help improve the quality of code so that it works fairly stable?

Generally, I do not suspect memory leak in any native PowerShell functionalities, however, there are instances where cmdlets (e.g. that offer WinForms based UI) via DLLs are made available and are used in the code. Also, as mentioned somewhere above, there imports of .NET types that are being used. I believe that could still lead to memory leaks.

Microsoft Technologies based on the .NET software framework.
3,534 questions
.NET Runtime
.NET Runtime
.NET: Microsoft Technologies based on the .NET software framework.Runtime: An environment required to run apps that aren't compiled to machine language.
1,137 questions
Windows Server PowerShell
Windows Server PowerShell
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.PowerShell: A family of Microsoft task automation and configuration management frameworks consisting of a command-line shell and associated scripting language.
5,432 questions
{count} votes