Analyze SetupDiag errors for Feature Updates in ConfigMgr 2008 Technical Preview

August 12, 2020

As soon as I read the release notes for ConfigMgr 2008 Technical Preview I knew I would be doing some digging. This release introduced the first iteration of a feature that will hopefully help make Windows 10 Feature Update servicing a little easier to manage. Listed as Analyze SetupDiag errors for feature updates this feature has been added to the Windows 10 Servicing dashboard. When I initially read the release notes and looked at the included graph, I was disappointed. I’ve seen these number before. They appear in the Monitoring node for any Feature Update deployment using servicing. But I did some digging and have now renewed faith that future Updates of this Feature (see what I did there? Feature Update… ah forget it). Read on for all the juicy details.

Screenshot of Collection Errors tile in Windows 10 Servicing dashboard

It’s VERY important to note that this is the first iteration of this feature and it should be treated as ‘In Progress’. As is the case with Technical Previews, features can change and possibly not even get released. So this blog only serves as a place to keep some notes on this feature as it stands today.

What’s the Big Deal?

If you have done any work with Windows 10 Feature Updates, you’ll know that gathering logs and information about failures can be difficult and often, the error code alone isn’t enough to help diagnose the failure. With the introduction of Windows 10 2004, the Windows Setup team enabled SetupDiag to run automatically when a Feature Update fails. SetupDiag writes a registry key to HKEY_LOCAL_MACHINE\SYSTEM\Setup\setupdiag\results that looks like this:

Side note: The default location for the SetupDiag registry key is HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup\Volatile\SetupDiag. However when it is triggered as part of a failure in Windows 10 2004 and later, the registry path is HKEY_LOCAL_MACHINE\SYSTEM\Setup\setupdiag\results. More details here.

Limitations

Currently, this feature can only be triggered by a FAILED Windows 10 2004 Feature Update, delivered as an update using servicing (not a Task Sequence). There’s no way to manually run SetupDiag and trigger the data collection used by the Windows 10 Dashboard.

Testing it Out

To test this, I built a new domain-joined Hyper-V VM with Windows 10 1909 and installed the ConfigMgr client. Then I added a registry key that I found in the Appraiser Database that would cause setup to fail (more on my research into blocks here).

Then I created a deployment to my workstation collection (In my lab that’s All Systems 😃) for Feature update to Windows 10 (business editions), version 2004, en-us x64 from \Software Library\Overview\Windows 10 Servicing\All Windows 10 Updates

On the client, I triggered a Software Update deployment cycle and the update showed up in Software Center. I started the install then went to have dinner. When I returned I was greeted by this amazing screen!

This was exactly what I was hoping for. Next I refreshed the Windows 10 Servicing dashboard in the ConfigMgr console and there it was, my beautiful graph!!

As far as I can tell, there’s no drill-through option just yet, but I think it will be added in time.

On the client, I was able to use WMIExplorer (bless you Vinay) to find the message in the ROOT\CCM\StateMsg CCM_StateMsg under TopicType <strong>402**. I didn’t know which TopicType to look for, so I just clicked through the entries to find SetupDiag in the StateDetails property.

The contents of StateDetails is a snippet of the SetupDiag registry entry shown above.

<SetupDiag>
    <ProfileName>FindAbruptDownlevelFailure</ProfileName>
    <DateTime>8/11/2020 6:38:20 PM</DateTime>
    <FailureData>Error: SetupDiag reports abrupt down-level failure.Last Operation: FinalizeError: 0xC1900208 - 0x4000D LogEntry: 2020-08-11 18:37:56, Error                 MOUPG  CSetupManager::ExecuteInstallMode(868): Result = 0xC1900208 Refer to "https://docs.microsoft.com/windows/desktop/Debug/system-error-codes" for error information.</FailureData>
    <SetupDiagVersion>1.6.0.0</SetupDiagVersion>
    <ProfileGuid>55882B1A-DA3E-408A-9076-23B22A0472BD</ProfileGuid>
    <Remediation>null</Remediation>
    <FailureDetails>ErrorCode = 0xC1900208, ExCode = 0x4000D, Oper = Finalize</FailureDetails>
</SetupDiag>

You can get fancy and use PowerShell to query the values as well now that we know to look for TopicType 402.

PS C:> Get-CIMInstance -NameSpace 'ROOT\ccm\StateMsg' -ClassName CCM_StateMsg -Filter "TopicType = '402'"

Criticality      : 1
MessageSent      : True
MessageTime      : 8/11/2020 6:38:21 PM
ParamCount       : 5
Priority         : 5
Reserved1        :
Reserved2        :
Reserved3        :
StateDetails     : <SetupDiag><ProfileName>FindAbruptDownlevelFailure</ProfileName><DateTime>8/11/2020 6:38:20
                   PM</DateTime><FailureData>Error: SetupDiag reports abrupt down-level failure.Last Operation:
                   FinalizeError: 0xC1900208 - 0x4000D LogEntry: 2020-08-11 18:37:56, Error                 MOUPG
                   CSetupManager::ExecuteInstallMode(868): Result = 0xC1900208 Refer to
                   "https://docs.microsoft.com/windows/desktop/Debug/system-error-codes" for error information.</Failur
                   eData><SetupDiagVersion>1.6.0.0</SetupDiagVersion><ProfileGuid>55882B1A-DA3E-408A-9076-23B22A0472BD</Profi
                   leGuid><Remediation>null</Remediation><FailureDetails>ErrorCode = 0xC1900208, ExCode = 0x4000D, Oper =
                   Finalize</FailureDetails></SetupDiag>

StateDetailsType : 1
StateID          : 11
TopicID          : Site_68DCD582-5CAE-4DC2-BFD4-4DA40B2452B5/SUM_1656cdd2-2e73-4fd8-9ab9-02097d5c7544
TopicIDType      : 5
TopicType        : 402
User             :
UserFlags        : 2
UserParameters   : {200, , 1, -1073730116...}
UserSID          :
PSComputerName   :

You can also see the 402 messages get generated in StateMessage.log on the client.
Adding message with TopicType 402 and TopicId Site_68DCD582-5CAE-4DC2-BFD4-4DA40B2452B5/SUM_1656cdd2-2e73-4fd8-9ab9-02097d5c7544 to WMI
State message(State ID : 3) with TopicType 402 and TopicId Site_68DCD582-5CAE-4DC2-BFD4-4DA40B2452B5/SUM_1656cdd2-2e73-4fd8-9ab9-02097d5c7544 has been recorded for SYSTEM

If we check SQL, we will find that the XML data is stored in the Update_ComplianceStatus table. Notice that the LastErrorCode is the same as the error in our chart in the dashboard -1047526904.

SELECT 
	CI_ID,
	MachineID,
	LastErrorCode,
	LastErrorDetail
FROM
	Update_ComplianceStatus 
WHERE 
	LastErrorDetail IS NOT NULL

I know what the code is going to translate to but was going to use an online converter to convert it when I stumbled upon the Microsoft Error Lookup Tool. It couldn’t translate the NTSTATUS code for me, but it at least converted from decimal to NTSTAUS
No results found for hex 0xc1900208 / decimal -1047526904

As you can see the error 0xc1900208 is the same listed in the XML above that SetupDiag harvested. Plus now we have the error text to go with it instead of having to go dig it out of the Upgrade Error Codes page (raise your hand if you’ve been there before and questioned your where you went wrong in life that led you there!).

That’s about everything I’ve found in this one.

Things to Come

So, as you can see, while the Windows 10 Servicing dashboard isn’t fully fleshed out yet, there is a fair amount of work that’s already been done to begin pulling this data in. In this iteration, I don’t see much value in the feature, but I can see where it’s headed and I’m hopeful! I don’t know what the next release will have in it but I HOPE that most of what I’ve written here gets updated expanded upon. Also, if you find yourself reading this post a month or more from today (August 6, 2020), chances are, this is obsolete. Check the next releases for updates.