Hi, ControlUp users! Today I want to briefly discuss a new Community SBA that was posted recently, “Display DLLs loaded by process”.
We had a request to be able tell which DLLs are loaded by a given process. Why would we want to do that? It seems that sometimes a program may be misbehaving on a particular computer and as part of the troubleshooting process, it would be good to know exactly which DLLs have been loaded (or not loaded) by the process. Or maybe we are in some form of DLL hell, and the right DLL name is loading from the wrong location. How can we tell? PowerShell has a cmdlet called Get-Process that will give us exactly that information, so we are in luck.
Creating an SBA that uses that function is a very similar process to the SBA that Yoni demonstrated for us earlier (see). First, from the Scripts Management window, we click the ‘New’ button, and fill out the basic information below. Note that since this SBA is meant to work against Processes, it is assigned to the Process object type. We also want this script to run on the targeted computer, so we make that choice. Lastly, the Local System security context is a good choice for being able to see all of the process running on the computer and reporting the DLL information from it, so let’s leave the default choice there.
What about the PoSh script itself? All we really need is to use the Get-Process function and display only the loaded modules, so the one-liner
(Get-Process -PID $args -ErrorAction Stop).Modules | ft FileName
is really all we need. (The $args variable comes from the next tab) –
But we like to put some error handling around the main part of our scripts so that if there is a problem, it is a little easier to troubleshoot. We use the Try/Catch blocks to help us here:
$Modules = (Get-Process -PID $args -ErrorAction Stop).Modules
$_ | fl *
$Modules | ft FileName
In this contruct, $_ displays the error returned from Get-Process. ‘Exit 1’ makes sure that the script exits with an error that we can see in the results window.
That’s it! When we save the SBA, it goes to the ‘My Drafts Folder’ where I was able to test it in a few scenarios. Then I clicked the ‘Finalize’ button, but unchecked ‘Yes, I want to share my work with the community’ because I wanted to test it against multiple targets in our organization before sharing it with the community. Let’s see what happens:
Here is the SBA results window:
Well, the script ran successfully on both servers. If there were any errors during script execution, we would see them here as well. We see that the results have been placed in two separate groups. That happens any time that the output is different, so I’ll copy/paste the results of each server into text files and compare them to find out why.
Hmm. Notepad does not load all of the same DLLs on Server13 that it does on Server14. That’s some nice, quick troubleshooting there.
The SBA as defined worked just fine with multiple processes, and we see here that CuXen65TS13 seems to have disabled the Citrix API hooks for notepad.exe. That could explain a problem we saw with Notepad on TS13 that didn’t happen on the other servers. I’ll have to talk to our Citrix admin about that. (Hey, Yoni…)
Since our testing was successful, let’s share it with the rest of the ControlUp users by clicking the ‘Share’ button in the ‘Organizational Actions’ tab of the Scripts Management window. This allows me to share the SBA similar to the ‘Finalize’ button on the Drafts tab.
After a quick review by the Smart-X support team, it was approved for use and now everyone has the opportunity to download and use this script.
I hope this helps encourage you to not only use the SBA feature, but also to explore creating your own SBAs and sharing them with the ControlUp community. It’s easy to do, and who knows, we might feature your SBA in a future blog post!