Analyze SetupDiag errors for Feature Updates in ConfigMgr 2008 Technical Preview

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.

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.


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.

 2    <ProfileName>FindAbruptDownlevelFailure</ProfileName>
 3    <DateTime>8/11/2020 6:38:20 PM</DateTime>
 4    <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 "" for error information.</FailureData>
 5    <SetupDiagVersion></SetupDiagVersion>
 6    <ProfileGuid>55882B1A-DA3E-408A-9076-23B22A0472BD</ProfileGuid>
 7    <Remediation>null</Remediation>
 8    <FailureDetails>ErrorCode = 0xC1900208, ExCode = 0x4000D, Oper = Finalize</FailureDetails>

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

 1PS C:> Get-CIMInstance -NameSpace 'ROOT\ccm\StateMsg' -ClassName CCM_StateMsg -Filter "TopicType = '402'"
 3Criticality      : 1
 4MessageSent      : True
 5MessageTime      : 8/11/2020 6:38:21 PM
 6ParamCount       : 5
 7Priority         : 5
 8Reserved1        :
 9Reserved2        :
10Reserved3        :
11StateDetails     : <SetupDiag><ProfileName>FindAbruptDownlevelFailure</ProfileName><DateTime>8/11/2020 6:38:20
12                   PM</DateTime><FailureData>Error: SetupDiag reports abrupt down-level failure.Last Operation:
13                   FinalizeError: 0xC1900208 - 0x4000D LogEntry: 2020-08-11 18:37:56, Error                 MOUPG
14                   CSetupManager::ExecuteInstallMode(868): Result = 0xC1900208 Refer to
15                   "" for error information.</Failur
16                   eData><SetupDiagVersion></SetupDiagVersion><ProfileGuid>55882B1A-DA3E-408A-9076-23B22A0472BD</Profi
17                   leGuid><Remediation>null</Remediation><FailureDetails>ErrorCode = 0xC1900208, ExCode = 0x4000D, Oper =
18                   Finalize</FailureDetails></SetupDiag>
20StateDetailsType : 1
21StateID          : 11
22TopicID          : Site_68DCD582-5CAE-4DC2-BFD4-4DA40B2452B5/SUM_1656cdd2-2e73-4fd8-9ab9-02097d5c7544
23TopicIDType      : 5
24TopicType        : 402
25User             :
26UserFlags        : 2
27UserParameters   : {200, , 1, -1073730116...}
28UserSID          :
29PSComputerName   :

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.

2	CI_ID,
3	MachineID,
4	LastErrorCode,
5	LastErrorDetail
7	Update_ComplianceStatus 
9	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.