Troubleshooting: Tracking down what executed updates in Windows 10

“Why did I get an update installed on my Windows 10 machine?”

At first blush, this sounds like an easy-peasy kinda question to answer. But in a managed enterprise, with multiple IT departments that might not always play nice together, this can be a prickly subject. Because the question really isn’t “Why did this update install?”. It is usually something more like the CEO asking “Why did my PC slow down while I was in a board meeting presentation?”

And again, it’s a fair question. And should be easy. Except when it isn’t. Like today.

“Which management system we use caused an update to occur at this particular time point?”

For this, on 10 I asked for the output of Get-WindowsUpdateLog in an administrative PowerShell prompt. But the output came back formatted weirdly. Snippet below with removing some info (date, time made up)

2018/07/XX 5:55:03.0332383 149280 120000 Unknown( 13): GUID=a2b43708-af59-32cd-48bc-7cf111dee98e.
2018/07/XX 5:55:04.9808283 149280 120000 Unknown( 16): GUID=a2b43708-af59-32cd-48bc-7cf111dee98e.
2018/07/XX 5:55:04.9819252 149280 149372 Unknown( 19): GUID=1bce64d0-3b5c-3a28-bd28-0e6a0b1dc374.
2018/07/XX 5:55:08.2263039 4872 148044 Unknown( 12): GUID=26bba210-72d3-3f28-a89e-6bdc4716006d.
2018/07/XX 5:55:08.2263914 4872 148044 Unknown( 12): GUID=26bba210-72d3-3f28-a89e-6bdc4716006d.
2018/07/XX 5:55:08.2264610 4872 148044 Unknown( 18): GUID=8bc93df4-dfb7-3bd8-4da6-97dda6e01d4f.
2018/07/XX 5:55:29.5807238 4872 148180 Unknown( 19): GUID=7d6df39d-a28f-39fb-0934-ccd9f7428391.
2018/07/XX 5:55:29.5807720 4872 148180 Unknown( 63): GUID=d7143c12-c53a-301e-eff4-e0e2b985334a.

Ok….

So I have PID and I have presumably Thread ID. Don’t know what the process, or what it was doing, and then a GUID which might be helpful.

As it turns out I had previously given the customer instructions on how to collect ETW traces for me using WPRui. So we also had a trace too!

In the trace, my first question was “Did my product cause this?”

In it we found lots of disk activity, but nothing related to updates at all.

So I then tracked down the PID 149280 in the ETW trace, using WPA.

So, it’s a PIA to look manually for PID appended to all these process ids…I could ctrl+F and search in column for my PID, or I could add the PID value to the columns by right clicking a column and checking the box for PID. I searched.

Ok, so now we know the PID is MonitoringHost.exe…this doesn’t sound like something that would be pushing updates to a system, or does it?

Let us pretend we don’t know, how do we find out what this is? Couple ways, add a path to the process view I showed above will give a hint usually. The other would be to look for the parent PID and see who owns it. Lets do both…

Awesome. It’s the Microsoft Monitoring Agent. I k now from reading https://blogs.technet.microsoft.com/msoms/2016/08/17/the-many-faces-of-the-microsoft-monitoring-agent/ that this is some part of either SCOM/SCCM/OMS/Whatever else uses this common binary…

So what is it doing? Let us stack walk shall we?

I add a view from Computation in WPA to the Analysis view. Specifically ‘CPU Usage (Sampled)’, change it to Usage by Process, Stack. Then add Module and Function. I then find my process and right click/filter to selection to remove all other processes. Then simply right click the stack column and select ‘Expand Column’.

I see this is running .net, but I really only care about stacks from the specific binaries, so I scroll down a bit…

And I see this stack

This kinda stood out to me… (truncated them so they wouldn’t line wrap on a browser window… or trying to do that. Whatever I don’t know WordPress.)

OMSRunbookWorkerRegistration.dll!AgentService.OmsHybridRegistration.PowerShell.Commandlets.OmsHybridRunbookWorker

and

Hybrid.Registration.Cmdlets.dll!AgentService.HybridRegistration.PowerShell.Registry.HybridWorkerRegistry

Ok, so now I know it’s OMS code, running runbooks. Lets see what that does…

https://docs.microsoft.com/en-us/azure/automation/automation-update-management Spells it out pretty well…

Computers that are managed by Update Management use the following configurations to perform assessment and update deployments:

Microsoft Monitoring Agent (MMA) for Windows or Linux
PowerShell Desired State Configuration (DSC) for Linux
Automation Hybrid Runbook Worker
Microsoft Update or Windows Server Update Services (WSUS) for Windows computers

Well ok, I see Runbook Worker Registration happening, so it’s running that. Looks pretty likely this is what’s causing Windows Updates to patch.

 

Again, why?

Because I saw the PID of the process referenced in the WindowsUpdate Log

I analyzed the code the PID is running and I see clearly that it is running code for components that are used by an Azure patch automation offering.

How did it get there on the machine? Don’t know, not enough data, maybe someone testing out something, or configured into this by accident. Magic 8 ball says “future is uncertain”.

 

Peace!

Jeff Stokes

Leave a comment

Your email address will not be published. Required fields are marked *

Exit mobile version