PowerShell is an extremely powerful scripting language. Not only can you utilize the set of cmd-lets given to you by default, but you can tap .NET classes to help you accomplish nearly whatever your heart may desire. A word of advice for you, however, if you plan on doing this…
What is going on?!
Having come from a non-managed code background, I’m usually very careful about cleaning up after myself when dealing with result sets and memory that isn’t used anymore. When I’m in a pinch, though, I have been known to forego a few things in the interest of time. Consider the following script:
$myComputer = "localhost"
$myRegistry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine',$myComputer)
$myRegKey = "Software\Microsoft\Windows NT\CurrentVersion"
$myRegValue = $myRegistry.OpenSubKey($myRegKey)
Write-Host $myRegValue.GetValue("ProductName")
Assuming that $myComputer is a valid computer name, you can contact it on the network, and you have rights to look at the registry, the above script will output the string Windows version currently installed on that machine (i.e. “Windows Server 2008 R2 Standard”). For a one-off, this works well as it is quick and to the point. You get what you came for with minimal effort, right?
I found myself running a bit larger of script that included quite a bit more data points to grab information off of approximately 1,600 computers the environment. Around 800 computers into the initial run, the computer I was running the script on remotely would stop processing through the list. Thinking it might have been something to do with the computer I was running it on, I brought the script back to my local machine and started running it there.
800 computers in, my display flickers and catches my attention. Windows displays a message that my graphics card driver crashed and that it has recovered from the error. I stop the script and look on bewildered. I had never seen a PowerShell script cause a display driver crash like that before. I ran the script again, except this time I kept Task Manager open and kept an eye on CPU and Memory information. Not a single concern there. CPU and memory were fine.
After watching the CPU and memory and seeing that they were fine, I thought that maybe the script was having trouble with the number of results being output, so I worked to implement a paging system that wrote x computers to temporary files and then combined them all at the end. After implementation, I ran the script again, but got the same result. I cancelled the test and scoured the code to see if I could find out why this was happening, and eventually found the problem…
Always Close Your Result Sets
When utilizing .NET classes in PowerShell, always check to see if the class you are getting back as a result has a close method. I typically make sure to do this when coding or scripting, but as I said before, this time I didn’t because the quick mashup script against a few servers quickly turned into a bigger deal.
Why is this bad? What caused this to happen?
Unless you programmatically close the resulting object returned by the calls you make, the resources utilized by the result set will remain in use until the end of script execution.
For quick, dirty, get stuff done scripts this isn’t a problem. When you need to iterate this over a large list of computers, however, those resources that remain utilized start to stack up quick. In this case, it wasn’t a CPU or memory issue, but rather an exhaustion of resources available to make the call to pull registry data.
By tacking on these two simple close methods, I stopped my crashing issue:
$myRegValue.Close() $myRegistry.Close()
Moral of the story? Take the miniscule amount of time it takes to type the close commands to save yourself a bunch of troubleshooting time in the off chance the script/application you’re working on has its scope expand.
As always, be careful and have fun!
