Summary: Ed Wilson, Microsoft Scripting Guy, talks about using Windows PowerShell to examine startup processes in Windows 10.
Microsoft Scripting Guy, Ed Wilson, is here. This morning I am playing with the Xbox One Smart Glass app on Windows 10. I have used the app since it was in beta, and I just got my Xbox One. But I have started using the Pandora app on my Xbox One, and I like to do stuff like mute advertisements, skip boring songs, change stations, and otherwise control the app.
Yeah, I can use my Xbox controller, and with a recent firmware update, it does connect faster, and has better battery life, but it is bulky on my workstation. I wanted something better, so I updated the Xbox One Smart Glass app. It works great. It connects fast, and I can do everything I want to do. Here is the screen layout:
I click the little remote control icon in the lower-right corner, and it opens an Xbox controller emulator that permits me to completely move around and do what I need to do. When I am done, I close it. Because it connects really fast, I don’t worry about having access to it. I pinned it to my Windows 10 start screen, so it is available. Cool. Some things just work.
The proliferating startup process problem
Some things just work, and then there are some things that seem to remain a pain. Windows startup applications are such a pain point—at least for me. I recently installed a new printer (which did not seem to have a driver, and instead required a quarter-gigabyte monolithic installation, and once installed, immediately required updating…yeah I know, I am a whiner) and a few other things required for work.
This morning I turned on my laptop, and behold! I was greeted with a notice that said I had so many startup applications that they were killing my poor three-year-old laptop…or words to that effect.
So I launched Task Manager, went to the Startup tab, and disabled a bunch of startup applications:
Using PowerShell to find startup processes
After I had disabled some startup processes via Task Manager, I decided to check on some other processes. I used Windows PowerShell to produce a list of startup processes. The command uses the Win32_StartUpCommand WMI class. To access this, I use the Get-CimInstance cmdlet (gcim is an alias):
The command and its output are shown here:
Hmmm. It looks like some of the processes I disabled are still running. Bummer. But before I throw my poor little laptop across the room and possibly break something (other than my laptop), I decide to use another WMI class to investigate things further.
This time I use the Win32_Process WMI class because it has the CommandLine property that will show me what command line is used to start a particular process. I can match that with the Command property from Win32_StartupCommand. There are a lot of processes running in Windows 10, and I want to filter some. First of all, I look for a command line that contains OneDrive:
gcim win32_process | where commandline -match 'onedrive'
Well, what about Lync?
gcim win32_process | where commandline -match 'lync'
Neither of these appear. So I decide to do a more generic Lenovo query. The output is shown here:
PS C:\> gcim win32_process | where commandline -match 'lenovo'
ProcessId Name HandleCount WorkingSetSize VirtualSize
——— —- ———– ————– ———–
2660 tphkload.exe 233 5353472 87777280
2668 micmute.exe 187 2768896 76730368
4032 tpnumlkd.exe 132 2363392 62742528
4376 tposd.exe 111 2011136 86228992
1288 shtctky.exe 130 1716224 93081600
5808 SynLenovoHelper.exe 129 2801664 90853376
6992 RAVBg64.exe 264 6230016 119590912
It appears that even though some of startup applications are listed, Task Manager is effectively disabling the apps. Cool. So sometimes things actually do work.
That is all there is to using Windows PowerShell to examine startup processes. Join me tomorrow when I will talk about PowerShell Saturday in Tampa.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy