30 days worth of Windows 11 Required Diagnostic Data

Microsoft has always been collecting data from customers in some form, but the subject of telemetry really hit the headlines when Windows 10 came along. The whole “What data are they taking?” and “Can I turn it off?” were the biggest questions being asked, of which it took a fair while to get any tangible answers. Oh, by the way, the answer to the latter question is still “no”, but I’m not here to go over old ground; instead, I want to look at the situation as it stands in Windows 11.

By default, Windows sends what is called “required diagnostic data”. Gone are the words “telemetry” that were so often thrown around like sweets for years, and now it’s the more friendly term “diagnostic data”. It sounds better, doesn’t it? Most can accept the thought of data being sent to Microsoft, for it is helpful to them in terms of diagnosing issues and improving Windows. If you go into the settings app, then privacy & security, then diagnostics and feedback, you can see that whether you chose to or not you are sending data … sorry, diagnostic data … to Microsoft; of course, you are sending data because you can’t turn it off. The “required” element of the data they say is necessary to keep your device (and presumably all windows devices by way of the vast amount of data they’ll get) secure, up to date and working as expected.

You might expect me to be writing this blog purely to be devil’s advocate about all this, but I’m totally fine with sending required diagnostic data to any company. I like to help make things better for everyone, so that’s fine. The bigger issue here is that very few of us really know what data is being sent to Microsoft. Don’t worry though, because there’s a nice write-up on Microsoft’s website and a handy app for you to see simply and easily what’s going to Microsoft and how often. Well, this all exists but I’d not call it suitable for bedtime reading unless you really are bored. The app does make it easier to know what’s being sent back to Microsoft, although I’d argue that it doesn’t make it anywhere near as clear or as simple as it could and should be.

Why I am writing this blog:

·         I wanted to try and give everyone a simpler picture of what Microsoft gets their hands-on from your computer and how often.

·         I want everyone to be more aware of the variety of data Microsoft collects from our devices.

·         Transparency – a word not always connected with Microsoft, but I wanted to enlighten us all and provide more transparency on the data collected from our devices but not because I think Microsoft is doing anything dodgy. I don’t think that.  

·         Despite its length, this blog post isn’t supposed to be comprehensive and tell you everything about everything. I’m not a Windows expert to that degree. I don’t know about every service and mechanism, but I know some things from my IT career.

Caveats:

·         I’m only looking primarily at how the typical Windows 11 device is set up in terms of sending diagnostic data to Microsoft. Thus, I’m concentrating on the default required diagnostic data.

·         If your computer is enrolled on the Windows Insider Programme, your default is to send full diagnostic data to Microsoft in order to receive future builds. Therefore, you’re sending much more back than I’ll detail here.

·         If you use Edge on a Windows Insider build, then there’s diagnostic data being sent from that application to Microsoft, of which one piece of data is search terms (unless you turn on private browsing).

·         I’m often on a metered network, not because I need to watch the amount of data I send but because I like the control it gives me over Windows Update downloads/installs. Therefore, the amount and frequency of diagnostic data being sent back to Microsoft could be more if you’re not on a metered connection.

Turn it on – The Diagnostic Data Viewer, that is.

If you want to find out what data Microsoft is taking from your device and when, the first thing is to install the app, called Diagnostic Data Viewer.

To do this you need to go to the settings app, then to Privacy and Security, and Diagnostics and Feedback where you see the screen below:

Go down to where it says View Diagnostics Data and turn it on.

Interestingly it says it uses up to 1GB of space. That seems unbelievably large when you are only asking to view diagnostic data that your computer is already creating and sending off to Microsoft. All you want to do is view it.

As it happens, it does not need to be set at 1GB and is customisable. In the app itself, you can set the storage size capacity from as little as 128MB, up to a whopping 10GB if you wish. The more data you set aside for it then the more events will be recorded in the viewer for a longer period of time.

The app itself is unremarkable and akin to throwing you in at the deep end as it lists all the diagnostic data events sent in chronological order in real-time and a side panel to show you the data in all its raw form:

To find out more about this app, go to https://docs.microsoft.com/en-us/windows/privacy/diagnostic-data-viewer-overview

What diagnostic data is “required”?

Well, thankfully this is all documented and I can tell you that Microsoft says that they collect data from 43 different event group types from Windows 11 devices, which I’m pleased to say is down by a massive 3 on what they say they collected that’s required in the latest version of Windows 10, which is V21H2.

In fact, what they have stopped and started collecting since that version of Windows 10 is just as interesting as everything else here. Well, it’s interesting in a geeky way. It must be said that the list of required data for the latest version of Windows 10 is the same as some of the previous versions of Windows 10, namely version 21H1, version 20H2 and … everyone’s favourite named version 2004.

One would naturally think therefore that the required data for each of those four flavours of Windows 10 has been consistently the same over their existence but I’ve no way of telling, and I also wouldn’t be surprised if they had changed slightly over the years, but alas all I can do is compare what is required in Windows 11 now with what Microsoft say is in the most recent version of Windows 10’s required data too.

For more detailed information go to https://docs.microsoft.com/en-us/windows/privacy/required-windows-11-diagnostic-events-and-fields although it can be quite patchy and confusing to read.

What’s new in Windows 11 Required Diagnostic Data?

Below is a list of event groups Microsoft has documented online as being required diagnostic data for Windows 11 but were not required in the latest version of Windows 10 (V21H2). There are ten of them, including, OOBE, which seems interesting to me that that wasn’t required the last time around.

If you’re looking at the below and wondering what they all mean, don’t worry, so am I. But I’m going to have a good go at explaining them as we go along.

·         AppPlatform events ·         Appraiser Events

·         Cloud experience host events

·         Code Integrity events

·         Feature quality events

·         Manufacturing events

·         OneSettings events

·         OOBE events

·         Servicing API Events

·         SIH events

·         UEFI events

What was required in the last version of Windows 10 but isn’t in Windows 11?

There are 13 required event groups in Windows 10 21H2 that are no longer listed as required in Windows 11:

•  Audio endpoint events
•  DXDiag events
•  Feedback events
•  MUI events
•  OneDrive events
•  ONNX runtime events
•  Settings events
•  Update notification events
•  Windows Defender events
•  Windows Store events
•  Winlogon events
•  XBOX events
•  XDE events

My 30 days’ worth of Required Diagnostic data

What I wanted to find out, to fulfil my curiosity, is what diagnostic data does my device send back to Microsoft? Along the way, I’d like to feel more secure that there’s no personal data in it (I’m not expecting any), and that I know how often it’s sending data and exactly what about. The idea here is to give me, and you, a clearer transparent picture that shows you an impression of what happens. Every device might well be slightly different, and I only have my own laptop to play with so I cannot say every device behaves the same but, remember, I am on Windows 11, I am only sending the default required diagnostic data, and I’m often using a metered connection. Microsoft Office or any other software sending diagnostic data to Microsoft (like Microsoft Edge) is outside the scope of this investigation.

So, first things first. I exported all the current data that the Diagnostic Data Viewer had to Excel where I could crunch some numbers and maybe create a few pivot graphs and formulae … Nah, just joking. I’ve no idea how to use anything more than the basics in Excel so I’m just going to figure out some rudimentary stats.

The data I exported was a month’s worth which matches up with the settings in the app which says 30 days. For those wondering, it was data for the period of 12^th February 2022 to 12^th March 2022.

During that time my device sent 3,514 diagnostic data events back to Microsoft. This means that in 30 days my device, on average, has sent 117 diagnostic data events of data per day to Microsoft. I’ll admit, that’s more than I expected but there several caveats here of course, not least that I don’t have my computer on the same amount of time every day. Often, it’s a few hours here and there, sometimes it is 5 hours but certainly never more than 5 hours in one day.

The 46 Windows 11 Required Diagnostic Data Event Groups

We will go through each of the 46 required groups of events in Windows 11 diagnostic data and see how often events from these groups occurred during my 30 days’ worth of data. I have to say right off the start, after getting through half of the groups whilst writing this blog I immediately began to wish I hadn’t started as I found a lot of it above my pay grade, confusing, and somewhat obfuscated but I persisted as I figured it was better to have a go at enlightening everyone than not at all. So, I apologise in advance if some areas seem bland or short, or basic. Also, some of the examples of the data in the events come from recent events of the same type which I’ve copy-pasted directly from the Diagnostic Data Viewer as these are formatted better for reading.

Ok, back to the 30 days of data. To help me crack this nut I’ve used a combination of Excel and Access to query all this data and help group it all together for me. Out of the 3,514 events that occurred during those 30 days, they can all be grouped together to show the most common events which occurred of which there were 106 events in total from those 46 groups.

You can see these 106 events below in order of frequency with the highest at the top. These 106 events all belong to the various 46 Required Data event group types in Windows 11. However, in 23 of those 46 groups I didn’t get any data at all for in those 30 days.

Here are the main events that occurred on my device in the 30 days:

322	Microsoft.OSG.DU.DeliveryOptClient.DownloadCompleted
322	Microsoft.OSG.DU.DeliveryOptClient.DownloadStarted
246	SoftwareUpdateClientTelemetry.CheckForUpdates
229	Aria.af397ef28e484961ba48646a5d38cf54.Microsoft.WebBrowser.Installer.EdgeUpdate.Ping
207	Microsoft.Windows.UpdateReserveManager.InitializeUpdateReserveManager
205	SoftwareUpdateClientTelemetry.Download
133	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates
133	TelClientSynthetic.HeartBeat_5
127	Microsoft.Windows.Inventory.Core.InventoryApplicationAdd
114	SoftwareUpdateClientTelemetry.UpdateMetadataIntegrity
93	SoftwareUpdateClientTelemetry.Install
88	SoftwareUpdateClientTelemetry.UpdateDetected
60	Microsoft.Windows.StoreAgent.Telemetry.StateTransition
58	Microsoft.Windows.Inventory.Core.InventoryApplicationRemove
52	SoftwareUpdateClientTelemetry.TaskRun
52	Update360Telemetry.UpdateAgentModeStart
50	Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoAdd
50	Microsoft.Windows.StoreAgent.Telemetry.EndAcquireLicense
47	Microsoft.Windows.Inventory.Core.InventoryDevicePnpRemove
44	TelClientSynthetic.ConnectivityHeartBeat_0
42	Aria.6660cc65b74b4291b30536aea7ed6ead.Microsoft.WebBrowser.SystemInfo.Config
38	Microsoft.Windows.WaaSMedic.SummaryEvent
36	Microsoft.Windows.Security.CodeIntegrity.State.IsProductionConfiguration
36	TelClientSynthetic.PrivacyGuardReport
35	Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorAdd
35	Update360Telemetry.UpdateAgentOneSettings
31	Update360Telemetry.UpdateAgentInitialize
30	Update360Telemetry.UpdateAgentMitigationResult
25	Microsoft.Windows.StoreAgent.Telemetry.EndDownload
25	Microsoft.Windows.StoreAgent.Telemetry.EndInstall
25	Microsoft.Windows.StoreAgent.Telemetry.FulfillmentComplete
25	Microsoft.Windows.StoreAgent.Telemetry.FulfillmentInitiate
24	DxgKrnlTelemetry.GPUAdapterInventoryV2
23	Microsoft.Windows.FeatureQuality.Heartbeat
22	Microsoft.Windows.Inventory.Core.InventoryDevicePnpAdd
22	Microsoft.Windows.UpdateReserveManager.InitializeReserves
20	Census.App
20	Microsoft.Windows.Inventory.Core.AmiTelCacheChecksum
19	Microsoft.Windows.OneSettingsClient.Heartbeat
16	Microsoft.Windows.Inventory.Indicators.Checksum
15	Census.Userdefault
15	Census.UserDisplay
15	Census.UserNLS
15	Census.UserPrivacySettings
15	Microsoft.OSG.DU.DeliveryOptClient.DownloadPaused
15	Microsoft.Windows.Appraiser.General.ChecksumTotalPictureCount
15	Microsoft.Windows.Appraiser.General.RunContext
15	Microsoft.Windows.Appraiser.General.TelemetryRunHealth
14	Microsoft.Windows.FaultReporting.AppCrashEvent
13	Aria.7005b72804a64fa4b2138faab88f877b.Microsoft.WebBrowser.SystemInfo.Config
12	Update360Telemetry.UpdateAgentDownloadRequest
10	Microsoft.Windows.Appraiser.General.SystemMemoryAdd
10	Update360Telemetry.UpdateAgentInstall
10	Update360Telemetry.UpdateAgentMitigationSummary
9	Microsoft.Windows.Kernel.PnP.AggregateClearDevNodeProblem
9	Microsoft.Windows.Kernel.PnP.AggregateSetDevNodeProblem
8	Microsoft.Gaming.Critical.ProviderRegistered
8	Microsoft.OSG.DU.DeliveryOptClient.FailureCdnCommunication
6	Update360Telemetry.UpdateAgentPostRebootResult
5	Microsoft.Windows.StoreAgent.Telemetry.ResumeInstallation
5	Microsoft.Windows.StoreAgent.Telemetry.ResumeOperationRequest
5	Update360Telemetry.UpdateAgentExpand
4	Census.Speech
4	Microsoft.Windows.Inventory.Core.InventoryDeviceMediaClassRemove
4	Microsoft.Windows.Kernel.DeviceConfig.DeviceConfig
4	Microsoft.Windows.UpdateReserveManager.BeginScenario
4	Microsoft.Windows.UpdateReserveManager.ClearReserve
4	SoftwareUpdateClientTelemetry.DownloadCheckpoint
3	CbsServicingProvider.CbsPackageRemoval
3	Microsoft.Windows.UpdateReserveManager.FunctionReturnedError
2	CbsServicingProvider.CbsQualityUpdateInstall
2	Census.Battery
2	Census.Enterprise
2	Census.Firmware
2	Census.Flighting
2	Census.Hardware
2	Census.Memory
2	Census.Network
2	Census.OS
2	Census.PrivacySettings
2	Census.Processor
2	Census.Security
2	Census.Storage
2	Census.VM
2	Census.WU
2	Microsoft.Windows.Inventory.Core.InventoryDriverBinaryAdd
2	Microsoft.Windows.Inventory.Core.InventoryDriverBinaryRemove
2	Microsoft.Windows.UpdateHealthTools.UnifiedInstallerEnd
2	Microsoft.Windows.UpdateReserveManager.EndScenario
2	Microsoft.Windows.UpdateReserveManager.ReevaluatePolicy
2	Microsoft.Windows.UpdateReserveManager.UpdatePendingHardReserveAdjustment
2	Mitigation360Telemetry.MitigationCustom.CleanupSafeOsImages
2	Mitigation360Telemetry.MitigationCustom.FixupWimmountSysPath
1	Aria.160f0649efde47b7832f05ed000fc453.Microsoft.WebBrowser.SystemInfo.Config
1	Microsoft.OSG.DU.DeliveryOptClient.DownloadCanceled
1	Microsoft.Windows.DriverInstall.DeviceInstall
1	Microsoft.Windows.DriverInstall.NewDevInstallDeviceEnd
1	Microsoft.Windows.DriverInstall.NewDevInstallDeviceStart
1	Microsoft.Windows.HangReporting.AppHangEvent
1	Microsoft.Windows.Inventory.Core.InventoryDriverPackageAdd
1	Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoStartSync
1	Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorStartSync
1	Microsoft.Windows.StoreAgent.Telemetry.SearchForUpdateOperationRequest
1	Microsoft.Windows.UpdateReserveManager.CommitPendingHardReserveAdjustment
1	Microsoft.Windows.UpdateReserveManager.PrepareTIForReserveInitialization
1	TelClientSynthetic.AbnormalShutdown_0

 

AppPlatform events

This is the first of the 46 required diagnostic data groups of events in Windows 11.

Microsoft’s documentation says “This event is required to track health of the install pipeline on the console. It tracks the install, the type of install, and the error codes hit during the install.”

Yeah, thanks for that clarity. What console huh? Xbox? I’m guessing that’s just a choice of word. What they appear to mean is that this event is triggered when you install something and will tell Microsoft what you installed and if it succeeded or failed. Maybe during the initial installation of the Operating System?

There’s only one event in this group and its title is InstallActivity yet the documentation details roughly 25 pieces of data that this event collects when triggered on your device which is sent back to Microsoft including the highly obvious data you’d expect like error codes and where you installed it from but also the download size, size of actual installer, and multiple things related to the installation. No name of the software though but there is ProductID which one assumes they will cross-correlate with what else you have installed or from a well-known list of Product GUIDs.

Did this event occur in my 30 days’ worth of data?

No.

The strangest thing here from my 30 days’ worth of data is that this event was not recorded once. I certainly did install at least two pieces of software during that time from the internet, and I even downloaded a random app from the Microsoft Store as I write this to see if it’s just store apps that are in this event, but nothing.

So, the result is that the true use of the AppPlatform event is a mystery at present.

 

Appraiser

This is one of the biggest of all diagnostic data event groupings in the required list as there are, wait for it, 127 appraiser events. Eeek.

Now, I’m not going to attempt to go through each one because, well, they are documented to some degree on the website, but I will have an attempt to give an overview.

What are appraiser events? Well, let’s get the dictionary out first, an appraiser is:

·         to estimate the monetary value of; determine the worth of; assess:

·         to estimate the nature, quality, importance, etc.:

Thus, by looking at this definition and also the 127 appraiser events below which I’ve listed (because I know you will want to read them all) it seems that these events are looking at the more deep system stuff on your device like BIOS, Processor and probably there’s some crossover to other types of events are a number of the appraiser events it says in the documentation make use of the data type for an inventory device change so I think an appraiser is some way looking at what’s changing on your device and if your device is performing with the specs it has.

127 appraiser events sitting on the wall …

·         Microsoft.Windows.Appraiser.General.ChecksumTotalPictureCount

·         Microsoft.Windows.Appraiser.General.DatasourceApplicationFileAdd

·         Microsoft.Windows.Appraiser.General.DatasourceApplicationFileRemove

·         Microsoft.Windows.Appraiser.General.DatasourceApplicationFileStartSync

·         Microsoft.Windows.Appraiser.General.DatasourceDevicePnpAdd

·         Microsoft.Windows.Appraiser.General.DatasourceDevicePnpRemove

·         Microsoft.Windows.Appraiser.General.DatasourceDevicePnpStartSync

·         Microsoft.Windows.Appraiser.General.DatasourceDriverPackageAdd

·         Microsoft.Windows.Appraiser.General.DatasourceDriverPackageRemove

·         Microsoft.Windows.Appraiser.General.DatasourceDriverPackageStartSync

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoBlockAdd

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoBlockRemove

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoBlockStartSync

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoPassiveAdd

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoPassiveRemove

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoPassiveStartSync

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoPostUpgradeAdd

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoPostUpgradeRemove

·         Microsoft.Windows.Appraiser.General.DataSourceMatchingInfoPostUpgradeStartSync

·         Microsoft.Windows.Appraiser.General.DatasourceSystemBiosAdd

·         Microsoft.Windows.Appraiser.General.DatasourceSystemBiosRemove

·         Microsoft.Windows.Appraiser.General.DatasourceSystemBiosStartSync

·         Microsoft.Windows.Appraiser.General.DecisionApplicationFileAdd

·         Microsoft.Windows.Appraiser.General.DecisionApplicationFileRemove

·         Microsoft.Windows.Appraiser.General.DecisionApplicationFileStartSync

·         Microsoft.Windows.Appraiser.General.DecisionDevicePnpAdd

·         Microsoft.Windows.Appraiser.General.DecisionDevicePnpRemove

·         Microsoft.Windows.Appraiser.General.DecisionDevicePnpStartSync

·         Microsoft.Windows.Appraiser.General.DecisionDriverPackageAdd

·         Microsoft.Windows.Appraiser.General.DecisionDriverPackageRemove

·         Microsoft.Windows.Appraiser.General.DecisionDriverPackageStartSync

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoBlockAdd

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoBlockRemove

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoBlockStartSync

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoPassiveAdd

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoPassiveRemove

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoPassiveStartSync

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoPostUpgradeAdd

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoPostUpgradeRemove

·         Microsoft.Windows.Appraiser.General.DecisionMatchingInfoPostUpgradeStartSync

·         Microsoft.Windows.Appraiser.General.DecisionMediaCenterAdd

·         Microsoft.Windows.Appraiser.General.DecisionMediaCenterRemove

·         Microsoft.Windows.Appraiser.General.DecisionMediaCenterStartSync

·         Microsoft.Windows.Appraiser.General.DecisionSModeStateAdd

·         Microsoft.Windows.Appraiser.General.DecisionSModeStateRemove

·         Microsoft.Windows.Appraiser.General.DecisionSModeStateStartSync

·         Microsoft.Windows.Appraiser.General.DecisionSystemBiosAdd

·         Microsoft.Windows.Appraiser.General.DecisionSystemBiosRemove

·         Microsoft.Windows.Appraiser.General.DecisionSystemBiosStartSync

·         Microsoft.Windows.Appraiser.General.DecisionSystemDiskSizeAdd

·         Microsoft.Windows.Appraiser.General.DecisionSystemDiskSizeRemove

·         Microsoft.Windows.Appraiser.General.DecisionSystemDiskSizeStartSync

·         Microsoft.Windows.Appraiser.General.DecisionSystemMemoryAdd

·         Microsoft.Windows.Appraiser.General.DecisionSystemMemoryRemove

·         Microsoft.Windows.Appraiser.General.DecisionSystemMemoryStartSync

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuCoresAdd

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuCoresRemove

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuCoresStartSync

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuModelAdd

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuModelRemove

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuModelStartSync

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuSpeedAdd

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuSpeedRemove

·         Microsoft.Windows.Appraiser.General.DecisionSystemProcessorCpuSpeedStartSync

·         Microsoft.Windows.Appraiser.General.DecisionTestAdd

·         Microsoft.Windows.Appraiser.General.DecisionTestRemove

·         Microsoft.Windows.Appraiser.General.DecisionTestStartSync

·         Microsoft.Windows.Appraiser.General.DecisionTpmVersionAdd

·         Microsoft.Windows.Appraiser.General.DecisionTpmVersionRemove

·         Microsoft.Windows.Appraiser.General.DecisionTpmVersionStartSync

·         Microsoft.Windows.Appraiser.General.DecisionUefiSecureBootAdd

·         Microsoft.Windows.Appraiser.General.DecisionUefiSecureBootRemove

·         Microsoft.Windows.Appraiser.General.DecisionUefiSecureBootStartSync

·         Microsoft.Windows.Appraiser.General.GatedRegChange

·         Microsoft.Windows.Appraiser.General.InventoryApplicationFileAdd

·         Microsoft.Windows.Appraiser.General.InventoryApplicationFileRemove

·         Microsoft.Windows.Appraiser.General.InventoryApplicationFileStartSync

·         Microsoft.Windows.Appraiser.General.InventoryLanguagePackAdd

·         Microsoft.Windows.Appraiser.General.InventoryLanguagePackRemove

·         Microsoft.Windows.Appraiser.General.InventoryLanguagePackStartSync

·         Microsoft.Windows.Appraiser.General.InventoryMediaCenterAdd

·         Microsoft.Windows.Appraiser.General.InventoryMediaCenterRemove

·         Microsoft.Windows.Appraiser.General.InventoryMediaCenterStartSync

·         Microsoft.Windows.Appraiser.General.InventorySystemBiosAdd

·         Microsoft.Windows.Appraiser.General.InventorySystemBiosRemove

·         Microsoft.Windows.Appraiser.General.InventorySystemBiosStartSync

·         Microsoft.Windows.Appraiser.General.InventoryTestAdd

·         Microsoft.Windows.Appraiser.General.InventoryTestRemove

·         Microsoft.Windows.Appraiser.General.InventoryTestStartSync

·         Microsoft.Windows.Appraiser.General.InventoryUplevelDriverPackageAdd

·         Microsoft.Windows.Appraiser.General.InventoryUplevelDriverPackageRemove

·         Microsoft.Windows.Appraiser.General.InventoryUplevelDriverPackageStartSync

·         Microsoft.Windows.Appraiser.General.RunContext

·         Microsoft.Windows.Appraiser.General.SystemMemoryAdd

·         Microsoft.Windows.Appraiser.General.SystemMemoryRemove

·         Microsoft.Windows.Appraiser.General.SystemMemoryStartSync

·         Microsoft.Windows.Appraiser.General.SystemProcessorCompareExchangeAdd

·         Microsoft.Windows.Appraiser.General.SystemProcessorCompareExchangeRemove

·         Microsoft.Windows.Appraiser.General.SystemProcessorCompareExchangeStartSync

·         Microsoft.Windows.Appraiser.General.SystemProcessorLahfSahfAdd

·         Microsoft.Windows.Appraiser.General.SystemProcessorLahfSahfRemove

·         Microsoft.Windows.Appraiser.General.SystemProcessorLahfSahfStartSync

·         Microsoft.Windows.Appraiser.General.SystemProcessorNxAdd

·         Microsoft.Windows.Appraiser.General.SystemProcessorNxRemove

·         Microsoft.Windows.Appraiser.General.SystemProcessorNxStartSync

·         Microsoft.Windows.Appraiser.General.SystemProcessorPrefetchWAdd

·         Microsoft.Windows.Appraiser.General.SystemProcessorPrefetchWRemove

·         Microsoft.Windows.Appraiser.General.SystemProcessorPrefetchWStartSync

·         Microsoft.Windows.Appraiser.General.SystemProcessorSse2Add

·         Microsoft.Windows.Appraiser.General.SystemProcessorSse2Remove

·         Microsoft.Windows.Appraiser.General.SystemProcessorSse2StartSync

·         Microsoft.Windows.Appraiser.General.SystemTouchAdd

·         Microsoft.Windows.Appraiser.General.SystemTouchRemove

·         Microsoft.Windows.Appraiser.General.SystemTouchStartSync

·         Microsoft.Windows.Appraiser.General.SystemWimAdd

·         Microsoft.Windows.Appraiser.General.SystemWimRemove

·         Microsoft.Windows.Appraiser.General.SystemWimStartSync

·         Microsoft.Windows.Appraiser.General.SystemWindowsActivationStatusAdd

·         Microsoft.Windows.Appraiser.General.SystemWindowsActivationStatusRemove

·         Microsoft.Windows.Appraiser.General.SystemWindowsActivationStatusStartSync

·         Microsoft.Windows.Appraiser.General.SystemWlanAdd

·         Microsoft.Windows.Appraiser.General.SystemWlanRemove

·         Microsoft.Windows.Appraiser.General.SystemWlanStartSync

·         Microsoft.Windows.Appraiser.General.TelemetryRunHealth

·         Microsoft.Windows.Appraiser.General.WmdrmAdd

·         Microsoft.Windows.Appraiser.General.WmdrmRemove

·         Microsoft.Windows.Appraiser.General.WmdrmStartSync

Did this event occur in my 30 days’ worth of data?

Yes.

55 times.

Perhaps the easiest way to make sense of these events is to see the frequency of events in this group in my 30 days’ worth of data:

·         15           Microsoft.Windows.Appraiser.General.ChecksumTotalPictureCount

·         15           Microsoft.Windows.Appraiser.General.RunContext

·         10           Microsoft.Windows.Appraiser.General.SystemMemoryAdd

·         15           Microsoft.Windows.Appraiser.General.TelemetryRunHealth

If we just look closer at the 4 types of appraiser events I got above, and let’s face it, that’s easier than looking at 127 types, we can see a bit more about what might be going on. Well, in theory.

In fact, there’s an order to these events and some sort of logic. Fancy that. I think this is all above my pay grade really and rather confusing, but the RunContext event merely tells us that it is CompatTelRunner.exe which ran, and by the looks of it this is the first appraiser event to run and merely initiates the other types of appraiser events. This is confirmed if I look at the Windows Diagnostic Viewer app for today on my device where you can see that RunContext is first. CompatTelRunner.exe is pretty much what it says on the tin, it’s checking the compatibility of aspects of your device, most likely in how well they are suited to future OS/Update upgrades.

If I look back over time, the last two of the above 4 always run after a RunContext, and that makes sense as they appear to be a validation of processes working. For the checksumTotalPictureCount event, Microsoft’s documentation goes a little like a politician on us by saying a lot but nothing in particular, for it says “This event lists the types of objects and how many of each exist on the client device. This allows for a quick way to ensure that the records present on the server match what is present on the client. The data collected with this event is used to help keep Windows up to date.” Obviously, this is a validation event of some sort and perhaps therefore a way that what’s on the device and what Microsoft has stored about what’s on your device are double-checked. There must be almost 100 data types in this particular appraiser event, so it certainly seems to be checking pretty much everything that the other 127 appraiser events record from your device.

SystemMemoryAdd doesn’t run every time a RunContext occurs, as you can see in my 30 days’ worth of data as it ran only ten times and everything else 15 times. Out of all the appraiser events that could be run, this is the easiest to understand as the documentation says in plain English “This event sends data on the amount of memory on the system and whether it meets requirement.” So, it seems that every few days or so, given it ran ten times in my 30 days’ worth of data, Microsoft likes to know how much memory is on your device. This isn’t just physical, but also there’s data on the virtual memory and pagefile information. Therefore, this gives some idea of performance to Microsoft.

What exactly is the “requirement” they want your device to meet though is a mystery.

Microsoft.Windows.Appraiser.General.ChecksumTotalPictureCount

"data": {

"PCFP": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}",

"InventoryApplicationFile": "1",

"InventoryMediaCenter": "1",

"InventoryLanguagePack": "1",

"InventoryUplevelDriverPackage": "0",

"InventorySystemBios": "1",

"SystemProcessorCompareExchange": "1",

"SystemProcessorLahfSahf": "1",

"SystemMemory": "1",

"SystemProcessorPrefetchW": "1",

"SystemProcessorSse2": "1",

"SystemProcessorNx": "1",

"SystemWlan": "1",

"SystemWim": "1",

"SystemTouch": "1",

"SystemWindowsActivationStatus": "1",

"InventoryTest": ""

}

 

Microsoft.Windows.Appraiser.General.RunContext

"data": {

"Time": "2022-06-01T13:15:53.4420000Z",

"PCFP": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}",

"AppraiserVersion": "10022000",

"AppraiserBranch": "WinBuild",

"AppraiserProcess": "CompatTelRunner.exe",

"Context": "Telemetry",

"Subcontext": "N/A"

}

 

 

Microsoft.Windows.Appraiser.General.SystemMemoryAdd

 

"data": {

"baseType": "Ms.Device.DeviceInventoryChange",

"baseData": {

"action": 1,

"objectType": "SystemMemory",

"objectInstanceId": "Memory",

"syncId": "{976bfdd5-34fd-4655-b466-fb19f1f1ba6a}",

"inventoryId": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}"

},

"AppraiserVersion": "10022000",

"ramKB": "6291456",

"pageFile": "12237053952",

"ram": "6331473920",

"virtual": "140737488224256",

"virtualKB": "137438953344",

"MemoryRequirementViolated": "FALSE",

"Blocking": "FALSE"

}

 

Microsoft.Windows.Appraiser.General.TelemetryRunHealth

 

"data": {

"Time": "2022-06-03T12:49:52.0280000Z",

"PCFP": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}",

"AppraiserVersion": "10022000",

"AppraiserBranch": "WinBuild",

"AppraiserProcess": "CompatTelRunner.exe",

"DeadlineDate": 131979240000000000,

"RunDate": 132987341918496265,

"AppraiserDataVersion": 2500,

"InboxDataVersion": 2500,

"RunAppraiser": false,

"RunGeneralTel": false,

"VerboseMode": false,

"EnterpriseRun": false,

"SendingUtc": false,

"ThrottlingUtc": false,

"PerfBackoff": false,

"PerfBackoffInsurance": false,

"StoreHandleIsNotNull": false,

"AuxInitial": false,

"AuxFinal": false,

"TelementrySent": false,

"IndicatorsWritten": false,

"RunOnline": true,

"FullSync": false,

"InventoryFullSync": false,

"CountCustomSdbs": 0,

"CustomSdbGuids": "",

"WhyFullSyncWithoutTablePrefix": "",

"RunResult": 1,

"ScheduledUploadDay": 12

}

 

Census

This is another chunky group of events, as there are 22 events under the bracket of “Census” diagnostic data:

·         Census.App

·         Census.Azure

·         Census.Battery

·         Census.Enterprise

·         Census.Firmware

·         Census.Flighting

·         Census.Hardware

·         Census.Memory

·         Census.Network

·         Census.OS

·         Census.PrivacySettings

·         Census.Processor

·         Census.Security

·         Census.Speech

·         Census.Storage

·         Census.Userdefault

·         Census.UserDisplay

·         Census.UserNLS

·        Census.UserPrivacySettings

·         Census.VM

·         Census.WU

·         Census.Xbox

 

Out of all the groups of events this one is easy to fathom as it simply is Microsoft grabbing data about your hardware, software, and configuration. There are a few interesting and less obvious events in the list above though, such as App which refers to data about the version of the Census App you have installed, not all the apps on your device. Azure is only relevant if your device is enrolled as an Azure Server (probably not many Windows 11 devices?) whereas it’s the enterprise event that is more about the traditional domain/cloud enrolment information, Flighting refers to returning information if your device is on an insider channel, privacy is Microsoft nosing to find out how secretive you setup your device in terms of USB, Webcam, Location, Ink etc in terms of if you’ve turned off or locked down those settings, Security primarily looks at your Windows Defender related settings, the oddly named UserNLS is about your language input and display language settings, UserPrivacy is the same as Privacy but specific to the current user, and WU refers to telling Microsoft about how well your computer has run updates in the past as well as your windows update settings.

Did this event occur in my 30 days’ worth of data?

Yes.

112 times.

Unsurprisingly, some of the Census events occurred more often than others. Two of the 22 types above didn’t occur at all: Azure and Xbox. That’s no surprise though for obvious reasons.

Top of the Census charts was the app event which was a constant offender telling Microsoft HQ that my device was running the Census App version 100220000120 and that the Appraiser Task was enabled.

Data about user settings occurred half of the 30 days, 15 times each, as you can see below. What may interest some readers is the UserDefault event which tells Microsoft what your default browser is, as well as other common file associations. For me, for example, the data sent back is:

"DefaultBrowserProgId": "ChromeHTML",

"DefaultApp": ".html:ChromeHTML|.htm:ChromeHTML|.jpg:AppX43hnxtbyyps62jhe9sqpdzxn1790zetc|.jpeg:AppX43hnxtbyyps62jhe9sqpdzxn1790zetc|.png:AppX43hnxtbyyps62jhe9sqpdzxn1790zetc|.mp3:AppXqj98qxeaynz6dv4459ayz6bnqxbyaqcs|.mp4:AppXqj98qxeaynz6dv4459ayz6bnqxbyaqcs|.mov:AppX6eg8h5sxqq90pv53845wmnbewywdqq5h|.pdf:MSEdgePDF|http:ChromeHTML|https:ChromeHTML|mailto:Thunderbird.Url.mailto",

"CalendarType": "1",

"ShortDateFormat": "dd/MM/yyyy",

"LongDateFormat": "dd MMMM yyyy",

"LocaleName": "en-GB"

 

Make of that what you will, but it seems that out of everything you set as a default, Microsoft is most interested in the browser, jpg, png, mp3, mp4, mov, pdf and mailto: - arguably all things Microsoft has inbuilt apps for, so they are more interested to tell from this what you are using instead of Edge, Media Player, Photos and Mail apps.

·         20           Census.App

·         2              Census.Battery

·         2              Census.Enterprise

·         2              Census.Firmware

·         2              Census.Flighting

·         2              Census.Hardware

·         2              Census.Memory

·         2              Census.Network

·         2              Census.OS

·         2              Census.PrivacySettings

·         2              Census.Processor

·         2              Census.Security

·         4              Census.Speech

·         2              Census.Storage

·         15           Census.Userdefault

·         15           Census.UserDisplay

·         15           Census.UserNLS

·         15           Census.UserPrivacySettings

·         2              Census.VM

·         2              Census.WU

 

Cloud experience host events

You’d think from the title of this event that this is something to do with perhaps OneDrive as that’s in the cloud but alas no, this event is according to the documentation related to OOBE.

Did this event occur in my 30 days’ worth of data?

No.

There’s no surprise here. If I had set up my device for the first time after it had arrived from a shop etc or a hard reset, then one might expect this event to be triggered but in normal practice, this event just isn’t going to happen every day, week, or year for most of us.

There are actually two sub-events to this one, a Microsoft.Windows.Shell.CloudExperienceHost.AppActivityRequired and a Microsoft.Windows.Shell.CloudExperienceHost.ExpectedReboot but as none of us are likely to ever be troubled by the knowledge of this data going to Microsoft more than once in a blue moon, I’m not going into more detail. Plus, it’s not exactly clear what part of the OOBE process this event would be triggered but suffice to say this is providing Microsoft with information about the setup of Windows first-time experience and that’s totally ok with me.

 

Code Integrity Events

It’s not easy working out what these events are all about and this one is another one of those best guesses. I can be certain this isn’t related to Microsoft checking if you can code correctly but more than likely to be something fundamental to critical Windows code, which is hinted by the titles of the 3 sub events under this branch:

·         Microsoft.Windows.Security.CodeIntegrity.State.Current

·         Microsoft.Windows.Security.CodeIntegrity.State.IsProductionConfiguration

·         Microsoft.Windows.Security.CodeIntegrity.State.PolicyDetails

Did this event occur in my 30 days’ worth of data?

Yes.

35 times.

Of the three events above, all 35 were the .IsProductionConfiguration event. This event, therefore, looks from what I can see to occur once a day and is likely reporting back that important code at the heart of Windows has or has not been compromised. Microsoft documentation says “This helps keep windows secure” so safe to say this is checking nothing has messed with the core of the Windows code.

What is it sending to Microsoft? Well, aside from lots of what I’d call header information like time/date, OS version, device hardware etc, the meat of the data in each of these events is simply the following:

·         "WldpIsWcosProductionConfiguration": true,

·         "RequiredConfigurationChecks": 0,

·         "FailedConfigurationChecks": 0,

One must go all Sherlock Holmes as a layman to know what this could all possibly mean and I’m no programmer or engineer, but I’d guess this is sort of saying that whatever its checking is as it expected, and no additional checks were required.

 

Common Data Extensions

One of the contenders for least interesting titles, this one has a few events associated with it:

·         Common Data Extensions.app

·         Common Data Extensions.container

·         Common Data Extensions.device

·         Common Data Extensions.Envelope

·         Common Data Extensions.mscv

·         Common Data Extensions.os

·         Common Data Extensions.sdk

·         Common Data Extensions.user

·         Common Data Extensions.utc

·         Common Data Extensions.xbl

But there’s a problem here in my attempts to understand this group of events even after looking at the documentation …

Did this event occur in my 30 days’ worth of data?

No.

Well, the exact data and understanding of this group of events is lost on me because it didn’t occur at all during the 30 days nor has it subsequently in the next 30 days of data as I look. Whatever it is, it doesn’t get triggered very often at all. It’s strange as the app event suggests it’s interested in apps that are running yet its use of the word container in various data fields of the events suggests it might be for specific apps only.

 

Common Data Fields

Possibly a nice easy one here as there’s only one type of event grouped under this which is MsDevice.DeviceInventoryChange and the documentation says, “Describes the installation state for all hardware and software components available on a particular device.” Brilliant! This couldn’t be easier to understand, except …

Did this event occur in my 30 days’ worth of data?

No.

So, one cannot elaborate on this type of event at all really except that it is referred to frequently in documentation in Appraiser and Inventory events as in “this event includes fields from this”. However, it doesn’t appear to run on its own but seems to have been picked at and butchered by other events.

 

Component-based Servicing Events

This section, despite the name, is all about Windows Updates. Why they need so many different named events covering the same thing I don’t know but I’m sure they have their reasons.

As you’ll see below, there are 7 types of events in this group:

·         CbsServicingProvider.CbsCapabilityEnumeration

·         CbsServicingProvider.CbsCapabilitySessionFinalize

·         CbsServicingProvider.CbsCapabilitySessionPended

·         CbsServicingProvider.CbsPackageRemoval

·         CbsServicingProvider.CbsQualityUpdateInstall

·        CbsServicingProvider.CbsSelectableUpdateChangeV2

·         CbsServicingProvider.CbsUpdateDeferred

 

The top 3 in the list above refer to information on optional updates you may install on your device. The CbsCapabilityEnumeration refers to results of Windows Update scanning your device for optional updates, CbsCapabilitySessionFinalize sends details of the result of installing or uninstalling an optional update, and CbsCapabilitySessionPended about Optional Updates that are installed but pending a reboot. CbsPackageRemoval sends back data about uninstalling a cumulative update, CbsQualityUpdateInstall provides metric information about how well a servicing update was installed, the cryptically named CbsSelectableUpdateChangeV2 reports on optional updates that have been disabled/enabled on the device, whereas the clearly named CbsUpdateDeferred is about sending data about updates being deferred although Microsoft totally omits any further details on what this contains.

Did this event occur in my 30 days’ worth of data?

Yes.

5 times.

Well, only 2 of the 7 events from this grouping occurred:

·         3              CbsServicingProvider.CbsPackageRemoval

·         2              CbsServicingProvider.CbsQualityUpdateInstall

I don’t personally recall removing any updates during those 30 days, so this is a little interesting. The actual data in the CbsPackageRemoval is about as much use as a guide to English flowers would be when you are trying to fix a computer:

data":{"majorVersion":22000,"minorVersion":493,"buildVersion":1,"revisionVersion":3,"currentStateEnd":0,"originalState":80,"hrStatusEnd":0,"failureSourceEnd":3,"clientId":"CbsTask","initiatedOffline":0,"transactionCanceled":0,"pendingDecision":1,"primitiveExecutionContext":4}}

How one knows what update it was I don’t know but I’m guessing they’ll figure it out from other events as they’ll get little from this one.

If you think that was not very useful data to us the layperson, then the CbsQualityUpdateInstall data is a classic:

data":{"stackRevision":469,"clientId":"UpdateAgentLCU","hrStatusEnd":0,"majorVersion":22000,"minorVersion":527,"buildVersion":1,"revisionVersion":7,"currentStateEnd":112,"originalState":64,"initiatedOffline":0,"primitiveExecutionContext":0,"planTimeSeconds":101,"resolveTimeSeconds":181,"stageTimeSeconds":628,"executeTimeSeconds":290,"preRebootTimeSeconds":383,"shutdownTimeSeconds":38,"rebootTimeSeconds":31,"postRebootTimeSeconds":29,"overallTimeSeconds":1682,"doqTimeSeconds":17,"poqTimeSeconds":21,"rptTimeSeconds":24,"rebootCount":1,"failureSourceEnd":0,"corruptionHistoryFlags":0,"corruptionType":0}}

It's likely that CBS is indeed more about statistics and measurable umm metrics to figure out performance rather than the actual nuts and bolts of the update. Interesting, looking at Event Viewer for the dates/times the above five events occurred, there were of course Windows Updates being installed (no sign of anything being removed though).

 

Deployment Events

For those in IT, this group of events does exactly what it says on the tin. It’s all about the deployment of images and there 5 types of events:

·         Microsoft.Windows.Deployment.Imaging.AppExit

·         Microsoft.Windows.Deployment.Imaging.AppInvoked

·         Microsoft.Windows.Deployment.Imaging.Failed

·        Microsoft.Windows.Deployment.Imaging.ImagingCompleted

·         Microsoft.Windows.Deployment.Imaging.ImagingStarted

 

Whether the App in the first two really means an application I can’t determine because there’s little data information in the documentation. As you’d expect, most of the data is in the completed and started events with the former giving the timings for the various stages of the deployment by the looks of it.

Did this event occur in my 30 days’ worth of data?

No.

This is hardly surprising given this isn’t the first time I’ve used this computer and I don’t tend to deploy images in the house. I wonder if I was setting up a device for the first time if these types of events would be triggered though?

 

Diagnostic Data Events

This is quite a juicy group of events because they centre around the telemetry client and have a shed load of data fields within most these events of which there are 6 types:

·         TelClientSynthetic.AbnormalShutdown_0

·         TelClientSynthetic.AuthorizationInfo_RuntimeTransition

·         TelClientSynthetic.AuthorizationInfo_Startup

·         TelClientSynthetic.ConnectivityHeartBeat_0

·         TelClientSynthetic.HeartBeat_5

·         TelClientSynthetic.PrivacyGuardReport

Although it’s got telemetry client in the title and that seems to be the main thrust here, it’s not all about the telemetry it seems because TelClientSynthetic.AbnormalShutdown_0 reports back to Microsoft HQ about, you guessed it, abnormal shutdowns, something we all have at some point when the OS crashes or your battery runs out of juice etc. This event sends back data about the battery, crash dumps, firmware, previous crashes counter, bugchecks, lots about the power button (how many times someone pressed it, released it, time and date it was last pressed and released, was a system shutdown in progress when it was pressed – who knew there were so many metrics about the power button!), sleep information, standby information and if it was a virtual machine. Phew. That’s a lot!

TelClientSynthetic.AuthorizationInfo_RuntimeTransition is back to the telemetry client itself and the documentation says at a particular (but not revealed) point in time it will report back on the data Microsoft is allowed to collect from the device. Given for us it’s usually required or optional you’d think it’ll be brief data this event returns, but no, it lets Microsoft know if they can report on MSA accounts, partner telemetry, userIDs, core/basic telemetry (hang on, it’s required and optional Microsoft!), heartbeats, diagnostic data, analytical events, are they allowed to add the device name to the data, SIUF or UIF escalation, a few other bits n bobs, including if the previous telemetry was all disabled (something that’s interesting as there’s no none way to turn this all off!).  

TelClientSynthetic.AuthorizationInfo_Startup is a clone of the previous event as it contains the same data except that this event is apparently reported at start-up (take note what I found in my 30 days’ worth of data), TelClientSynthetic.ConnectivityHeartBeat_0 is quite well explained in the documentation as “This event sends data about the connectivity status of the Connected User Experience and Telemetry component that uploads telemetry events. If an unrestricted free network (such as Wi-Fi) is available, this event updates the last successful upload time. Otherwise, it checks whether a Connectivity Heartbeat event was fired in the past 24 hours, and if not, it sends an event.” So, it’s basically just saying “Hey, Microsoft, the telemetry client is still working here / this device is still working”.  TelClientSynthetic.HeartBeat_5 takes things to Vulcan levels here as we’ve two heartbeats for the same client, yet this one is more about the quality of the client and how “trusted” its data is. Now, this doesn’t mean the actual data per se but more about how many errors have been detected either on the device in relation to the telemetry client or when it’s sending data to Microsoft HQ, so there’s a shed load of things about dropped events, counts and databases. TelClientSynthetic.PrivacyGuardReport makes one immediately think of Windows Security (or Windows Defender depending on what it’s called at this moment in time) but alas there’s no evidence it is. It’s all telemetry client related and relates to if it finds an event that contains privacy data. What privacy data you ask? Well, that’s rather unclear in this documentation.

Did this event occur in my 30 days’ worth of data?

Yes.

214 times.

This isn’t called required Diagnostic Data for nothing these days and there’s a decent number of events from this group triggered over the 30 days. However, from the 6 possible events, only 4 occurred and the two related to AuthorizationInfo are the two that didn’t show up despite the documentation saying one is triggered on startup and the other at an undefined time. Hmm.

1	TelClientSynthetic.AbnormalShutdown_0
44	TelClientSynthetic.ConnectivityHeartBeat_0
133	TelClientSynthetic.HeartBeat_5
36	TelClientSynthetic.PrivacyGuardReport

 

Now one abnormalshutodwn event did occur when my laptop shutdown (power cable popped out) so that all matches up. However, looking at the data in this event, how Microsoft is going to work out the Power Button times though on my device is debatable because the timestamps are clearly not correct. The year is 1601?

TelClientSynthetic.AbnormalShutdown_0

"data": {

"AbnormalShutdownBootId": 89,

"CurrentBootId": 90,

"LastSuccessfullyShutdownBootId": 88,

"PowerButtonLastPressBootId": 0,

"PowerButtonLastPressTime": "1601-01-01T00:00:00.0000000Z",

"PowerButtonLastReleaseTime": "1601-01-01T00:00:00.0000000Z",

"PowerButtonCumulativePressCount": 0,

"PowerButtonCumulativeReleaseCount": 0,

"PowerButtonLastReleaseBootId": 0,

"PowerButtonErrorCount": 0,

"TransitionInfoBootId": 89,

"TransitionInfoSystemRunning": 1,

"TransitionInfoSleepInProgress": 0,

"TransitionInfoCSInProgress": 0,

"TransitionInfoCSCount": 0,

"TransitionInfoSleepTranstionsToOn": 11,

"TransitionInfoPowerButtonTimestamp": "1601-01-01T00:00:00.0000000Z",

"TransitionInfoLastReferenceTimestamp": "2022-05-25T13:24:41.2441656Z",

"TransitionInfoLastReferenceTimeChecksum": 558499251,

"TransitionInfoLastBootDiagCode": 0,

"TransitionInfoLastBootDiagStatus": 0,

"FirmwareType": 1,

"CrashDumpEnabled": 7,

"LastBugCheckVersion": 0,

"LastBugCheckBootId": 0,

"LastBugCheckProgress": 0,

"LastBugCheckCode": 0,

"LastBugCheckParameter1": 0,

"LastBugCheckOriginalDumpType": 0,

"LastBugCheckOtherSettings": 0,

"LastBugCheckContextFlags": 0,

"CumulativeCrashCount": 0,

"PowerButtonPressIsShutdownInProgress": 0,

"PowerButtonPressLastPowerWatchdogStage": 0,

"PowerButtonPressPowerWatchdogArmed": 0,

"TransitionInfoCSEntryReason": 20,

"TransitionInfoCSExitReason": 25,

"PowerButtonPressCurrentCsPhase": 0,

"HardwareWatchdogTimerPresent": 0,

"HardwareWatchdogTimerGeneratedLastReset": 0,

"TransitionLatestCheckpointId": 0,

"TransitionLatestCheckpointType": 0,

"TransitionLatestCheckpointSeqNumber": 0,

"Firmwaredata->ResetReasonSupplied": 0,

"Firmwaredata->ResetReasonPch": 0,

"Firmwaredata->ResetReasonPchAdditional": 0,

"Firmwaredata->ResetReasonEmbeddedController": 0,

"Firmwaredata->ResetReasonEmbeddedControllerAdditional": 0,

"TransitionInfoUserShutdownInProgress": 0,

"TransitionInfoSystemShutdownInProgress": 0,

"TransitionInfoLidState": 1,

"AcDcStateAtLastShutdown": 1,

"BatteryLevelAtLastShutdown": 3,

"BatteryPercentageAtLastShutdown": 99,

"VirtualMachineId": "",

"LongPowerButtonPressDetected": 0,

"LongPowerButtonPressInstanceGuid": "{00000000-0000-0000-0000-000000000000}",

"ShutdownDeviceType": 255,

"OSSetupInProgress": 0,

"OOBEInProgress": 0,

"SleepCheckpoint": 38,

"SleepCheckpointStatus": 0,

"SleepCheckpointSource": 2,

"StaleBootStatData": 0,

"AbsCausedbyAutoChk": 0,

"InvalidBootStat": 0

}

}

The TelClientSynthetic.ConnectivityHeartBeat_0 event happened pretty much every day, but that total was only a third of the times TelClientSynthetic_hearbeat_5 occurred which I can see in my data happened a good 4 or 5 times every day.

Now the interestingly named TelClientSynthetic.PrivacyGuardReport spells out more clearly in its data that this is very much a telemetry client not Windows Defender event as we see below in an example from my device:

TelClientSynthetic.PrivacyGuardReport

"data": {

"EventName": "Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoAdd",

"FieldName": "objectInstanceId",

"TypeAsText": "SecurityIssue",

"IsAllowedToSend": false,

"IsDebug": false,

"TelemetryApi": "etw",

"EventEpoch": "9503596",

"EventSeq": 318

}

 

This event is therefore reporting on other diagnostic data events that contain privacy data, and as it’s a mostly daily occurrence, the event causing it to be triggered does vary throughout the 36 times this event happens although they are all inventory events.

 

DISM Events

‘DISM … I’m so DISM, my head is spinning. Like a whirlpool, it never ends.’ That’s the song that springs to mind today when I write this but alas IT bods all over the planet will know that DISM is all about images given it stands for Deployment Image Servicing and Management. This is a command-line tool that helps prepare and service those chunky windows images.

The events that occur in this group are:

·         Microsoft.Windows.StartRepairCore.DISMLatestInstalledLCU

·         Microsoft.Windows.StartRepairCore.DISMPendingInstall

·         Microsoft.Windows.StartRepairCore.DISMRevertPendingActions

·         Microsoft.Windows.StartRepairCore.DISMUninstallLCU

·         Microsoft.Windows.StartRepairCore.SRTRepairActionEnd

·         Microsoft.Windows.StartRepairCore.SRTRepairActionStart

·         Microsoft.Windows.StartRepairCore.SRTRootCauseDiagEnd

·         Microsoft.Windows.StartRepairCore.SRTRootCauseDiagStart

I won’t be going into this group any more closely though, for reasons explained below …

Did this event occur in my 30 days’ worth of data?

No.

As explained before, I’m not creating or deploying images on my device nor is this an OOBE experience of a first-time touch of my device. Anyone who knows DISM will understand what these events are likely recording but for most of us, we’re not going to see these triggered. Suffice to say, Microsoft though is interested in what happens when you first turn on a new device or you revert to an image on your device.

 

Driver Installation Events

Another relatively clear group of events here which is quite welcome what with all the obfuscating going on in Microsoft’s documentation. Drivers are of course nothing to do with Uber but instead code that enables the hardware to talk to the operating system. They are essential, and to this reason, Microsoft calls one of these events in the group “critical” but strangely not the other two.

The three events in this group are:

·         Microsoft.Windows.DriverInstall.DeviceInstall

·         Microsoft.Windows.DriverInstall.NewDevInstallDeviceEnd

·         Microsoft.Windows.DriverInstall.NewDevInstallDeviceStart

Deviceinstall is the critical one apparently because this is the one that sends back all the details about a driver that’s been installed, whether it succeeded or not. As you’d expect there’s information in here about INF files, driver version, manufacturer, error codes, how long install took, was the driver included with windows, and much more things specific to the install and the driver. This event seems so comprehensive that it’s interesting that there are also NewDevInstallDeviceStart  and NewDevInstallDeviceEnd events too which send back a handful of information about the start time of a driver install and the end time. Why one needs these as well as the comprehensive event I don’t know.

Did this event occur in my 30 days’ worth of data?

Yes.

3 times.

Apparently, I installed a driver during those 30 days even though I don’t remember doing so and it was a Dell driver no less on my Dell laptop as the following data shows:

data":{"SessionGuid":"08993274-541A-0F45-9E26-0C64ABC3E938","DeviceInstanceId":"ROOT\\SYSTEM\\0001","ParentDeviceInstanceId":"HTREE\\ROOT\\0","InstallDate":"2022-02-15T14:22:47.9452675Z","FirstHardwareId":"*DDDriver","MatchingDeviceId":"*dddriver","DriverInfName":"oem25.inf","GenericDriver":false,"OriginalDriverInfName":"dddriver64dcsa.inf","DriverInfSectionName":"DellDataVault_Install.NTamd64","ClassGuid":"4D36E97D-E325-11CE-BFC1-08002BE10318","DriverDate":"2021-07-26T00:00:00.0000000Z","DriverVersion":"2.0.6.0","DriverProvider":"Dell Technologies","DriverPackageId":"dddriver64dcsa.inf_amd64_3bed6326b6d247ae","SubmissionId":"29997800_14443808353804289_1152921505693708927","DriverDescription":"Dell Data Vault Control Device","ServiceName":"DDDriver","DeviceStack":"\\Driver\\DDDriver;\\Driver\\PnpManager","FirmwareDate":"1601-01-01T00:00:00.0000000Z","SetupMode":false,"Inbox":false,"Problem":0,"ProblemStatus":0,"ConfigFlags":0,"StartTime":"2022-02-15T14:22:47.5804937Z","EndTime":"2022-02-15T14:22:48.1071679Z","NeedReboot":false,"RebootRequiredReason":0,"DriverUpdated":false,"SecondaryDevice":false,"PendedUntilReboot":false,"FinishInstallUI":false,"FinishInstallAction":false,"LastInstallFunction":0,"DeviceInstalled":false,"DeviceConfigured":true,"Error":0}}

As it happens, I installed the Dell Support Assist software on this date, and part of its install included the driver above. I wasn’t aware it installed a driver but now I am, and so is Microsoft.

 

DxgKernelTelemetry Events

There’s only one event in this group and its DxgKrnlTelemetry.GPUAdapterInventoryV2 which is absolutely jammed packed with data fields to be sent to Microsoft. There are a good 50+ fields which will send to HQ details about your GPU/Display Driver, such as how much memory is dedicated to the GPU, how much VRAM is used, its file path, version of driver, file paths to all the various versions of DirectX it uses, information about its interface and more.

Did this event occur in my 30 days’ worth of data?

Yes.

24 times.

Not quite one a day. In fact, it was strangely erratic, with it sometimes reporting multiple times a day, daily, and then weekly during those 30 days. Goodness knows what triggered it, except that one of the data fields is supposed to tell us:

DxgKrnlTelemetry.GPUAdapterInventoryV2

"data": {

"version": 14,

"bootId": 94,

"aiSeqId": 8,

"MeasureEnabled": true,

"TelemetryEnabled": true,

"InterfaceId": "\??\PCI#VEN_8086&DEV_0116&SUBSYS_05711028&REV_09#3&11583659&0&10#{1ca05180-a699-450a-9a0c-de4fbe3ddd89}",

"GPUVendorID": 32902,

"GPUDeviceID": 278,

"SubVendorID": 4136,

"SubSystemID": 1393,

"GPURevisionID": 9,

"DriverVersion": "9.17.10.4459",

"DriverDate": "2016-05-19T00:00:00.0000000Z",

"DriverRank": 13705217,

"IsMiracastSupported": false,

"IsMsMiracastSupported": true,

"IsHybridDiscrete": false,

"IsHybridIntegrated": false,

"IsMPOSupported": false,

"IsHwSchEnabled": false,

"IsVirtualRefreshRateSupported": false,

"HwSchSupportState": 0,

"IsHwFlipQueueEnabled": false,

"HwFlipQueueSupportState": 0,

"IsLDA": false,

"IsMismatchLDA": false,

"IsPostAdapter": true,

"IsSoftwareDevice": false,

"IsRenderDevice": true,

"IsDisplayDevice": true,

"AdapterTypeValue": 11,

"IsRemovable": false,

"BrightnessVersionViaDDI": 0,

"WDDMVersion": 1200,

"DisplayAdapterLuid": 53420,

"GPUPreemptionLevel": 100,

"ComputePreemptionLevel": 100,

"TelInvEvntTrigger": 1,

"DedicatedVideoMemoryB": 33554432,

"DedicatedSystemMemoryB": 0,

"SharedSystemMemoryB": 1711276032,

"NumVidPnSources": 2,

"NumVidPnTargets": 8,

"NumNonVidPnTargets": 0,

"KMDFilePath": "\SystemRoot\system32\DRIVERS\igdkmd64.sys",

"DX9UMDFilePath": "DriverStore\FileRepository\nvdmwu.inf_amd64_26aa6356770b2e86\nvumdshimx.dll",

"DX10UMDFilePath": "DriverStore\FileRepository\nvdmwu.inf_amd64_26aa6356770b2e86\nvumdshimx.dll",

"DX11UMDFilePath": "DriverStore\FileRepository\nvdmwu.inf_amd64_26aa6356770b2e86\nvumdshimx.dll",

"DX12UMDFilePath": "",

"DDIInterfaceVersion": 12302,

"InterfaceFuncPointersProvided1": 140737488355327,

"InterfaceFuncPointersProvided2": 105553351196672,

"InterfaceFuncPointersProvided3": 0,

"Display1UMDFilePath": "",

"DriverWorkarounds": "0x00082000",

"IddPairedRenderAdapterLuid": 0

}

}

 

The data field TelInvEvntTrigger is the bunny that tells us why it decided to send a report of all your GPU information to HQ, be it because of GPU enumeration or telemetry asked for it. In the example above, the value is 1, which is what telemetry asked for it. In fact, that value is the same all 24 times my device sent this event.

 

Fault Reporting Events

You know when things crash in Windows, and you wonder if any of this error reporting actually gets to Microsoft? Well, you’ll be glad to know that now it does. Apparently, this isn’t the same as those Watson or Windows Error Reporting triggered crashes you’ll see. The text makes it clear that only certain crashes trigger this event. There’s also only one event associated with this group which is Microsoft.Windows.FaultReporting.AppCrashEvent and contains a reasonable but not a vast number of data fields. Obvious information being the app that’s crashed, timestamp, whether it was fatal or not, module details, package details (for store apps), what’s the processor architecture it crashed on and some more specific identification details.

Did this event occur in my 30 days’ worth of data?

Yes.

14 times.

It’s Windows! Of course, something crashed. Mind you, it’s not as frequent or as serious as I remember in the past. Most were audio drivers as I have a strange issue where with skype or zoom audio will crash and I’ll often need to restart that app. In the example below though it’s the settings app that’s crashed:

Data

":{

"ProcessId":6888,

"ProcessCreateTime":"2022-03-09T14:07:45.5169283Z",

"ExceptionCode":3221225477,

"ExceptionOffset":598405,

"AppName":"SystemSettings.exe",

"AppVersion":148431802007027722,"

AppTimeStamp":665244177,"

ModName":"MusUpdateHandlers.dll","

ModVersion":122254629172936714,"

ModTimeStamp":1157971278,"

PackageFullName":"windows.immersivecontrolpanel_10.0.6.1000_neutral_neutral_cw5n1h2txyewy"

PackageRelativeAppId":"microsoft.windows.immersivecontrolpanel",

"ProcessArchitecture":9,

"ReportId":"c7f23459-c5a0-489c-aa8b-8e9be15f66f6",

"Flags":0,

"AppSessionGuid":"00001AE8-0012-004F-036F-DF0CBF33D801",

"TargetAppId":"U:windows.immersivecontrolpanel_10.0.6.1000_neutral_neutral_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel",

"TargetAppVer":"10.0.6.1000_neutral_neutral!1991/01/30:14:02:57!26765!SystemSettings.exe",

"TargetAsId":23092,

"FriendlyAppName":"Settings",

"IsFatal":true

}}

 

Feature Quality Events

As a Windows Insider, the word feature for me signals this might be related to one of the major updates of Windows we all get each year, of which for Windows 11 there’s supposed to be one a year. Given there hasn’t been one yet for Windows 11 you’d think I’d see very little of this event?

Did this event occur in my 30 days’ worth of data?

Yes.

22 times.

Therefore, this is another one of those daily check-ins to Microsoft HQ.

In fact, there’s three events in the FeatureQuality group:

·         Microsoft.Windows.FeatureQuality.Heartbeat

·         Microsoft.Windows.FeatureQuality.StateChange

·         Microsoft.Windows.FeatureQuality.Status

Guess which one I saw in my 30 days’ worth of data? Yes, it’s the heartbeat. Neither of the other two happened at all, which seems to fit in with this being linked to a Feature Update. So, why is the heartbeat if no feature update in the last 30 days? Well, presumably because the original release of Windows 11 is in itself a feature update and the heartbeat is telling Microsoft something about components of this feature.

The data sent back never changes during my 30 days, of which it says:

"data": {

"Features": [

{

"featureId": 19638787,

"status": false,

"state": 2,

"variant": 0,

"payload": 0,

"stateKind": 4,

"flightId": "FX:117B9872",

"firstStatus": "1601-01-01T00:00:00.0000000Z"

},

{

"featureId": 25704915,

"status": true,

"state": 2,

"variant": 1,

"payload": 0,

"stateKind": 4,

"flightId": "FX:11DE1DCB",

"firstStatus": "1601-01-01T00:00:00.0000000Z"

},

{

"featureId": 35825666,

"status": true,

"state": 1,

"variant": 0,

"payload": 0,

"stateKind": 4,

"flightId": "FX:123DAFA1",

"firstStatus": "1601-01-01T00:00:00.0000000Z"

}

 

Yeah, I don’t know either, but I can say that it looks like the three features it’s interested in on my device are fine and that Microsoft likes to know about this every day.

 

 

Feature Update Events

Just the mere two events in this group:

·         Microsoft.Windows.Upgrade.Uninstall.UninstallFailed

·        Microsoft.Windows.Upgrade.Uninstall.UninstallFinalizedAndRebootTriggered

As the name says this is very much about those bigger updates to Windows OS which are supposed to be annual now in Windows 11. Whether the feature update succeeded or failed is the name of the game here although information is thin on the ground as the former event only has two fields which is the failure reason and the error code, whereas the latter event has … well … we don’t know because there’s nothing in the documentation about its fields.

Did this event occur in my 30 days’ worth of data?

No.

Unsurprisingly, given there’s not been a feature update for Windows 11 yet at this time of writing, there were no events captured by my device.

 

Hang Reporting Events

Everyone’s favourite Windows experience is an application that hangs around long after it’s crashed like a mark on your clothes you just can’t clean off, and there’s an event for that you’ll be pleased to know. Only the one though, in the form of Microsoft.Windows.HangReporting.AppHangEvent does have a shed load of data fields associated with it such as the application ID, processor architecture, process ID, and information about other related hanging process issues.

Did this event occur in my 30 days’ worth of data?

Yes.

Once … amazingly.

Unlike the Fault Reporting Events, this baby is about Windows Error Reporting, and probably that window we all can’t be bothered to wait to complete its task whilst it tries to report the issue.

What crashed for me in the 30 days? Interestingly, it was the Your Phone App, or Phone Link as it was renamed to.

data":{"ProcessId":11992,"ProcessCreateTime":"2022-02-24T13:57:20.1190146Z","TypeCode":2097152,"AppName":"YourPhoneServer.exe","AppVersion":1100895813633,"PackageFullName":"Microsoft.YourPhone_1.21121.256.0_x64__8wekyb3d8bbwe","PackageRelativeAppId":"App","WaitingOnAppVersion":0,"ProcessArchitecture":9,"ReportId":"857c69e1-ab9e-40e3-9856-cc901b35d8d1","AppSessionGuid":"00002ED8-0003-004F-0289-BC708629D801","TargetAppId":"U:Microsoft.YourPhone_1.21121.256.0_x64__8wekyb3d8bbwe!App","TargetAppVer":"1.21121.256.0_x64_!2022/02/01:22:08:42!f8d1!YourPhoneServer.exe","TargetAsId":3121,"IsFatal":false}}

Apparently, it wasn’t fatal, but the app did crash, so I’d think that was pretty fatal from a user perspective.

 

 

Holographic Events

Maybe I’m getting on in age, but I’m not a big VR/AR fan, although I’ve also hardly experienced a lot of it. As we know, Microsoft is really into it and lobbed lots of it into Windows 10 and henceforth it’s in Windows 11 too although thankfully a lot more hidden than in your face as it used to be. Given Microsoft’s love of ramming this stuff down our faces in their Operating Systems, it won’t surprise you to know there are several events in this group:

·         Microsoft.Windows.Analog.Spectrum.TelemetryHolographicDeviceAdded

·         Microsoft.Windows.Analog.Spectrum.TelemetryHolographicDeviceRemoved

·         Microsoft.Windows.Holographic.Coordinator.HoloShellStateUpdated

·         Microsoft.Windows.Shell.HolographicFirstRun.AppActivated

·         Microsoft.Windows.Shell.HolographicFirstRun.AppLifecycleService_Resuming

·         Microsoft.Windows.Shell.HolographicFirstRun.SomethingWentWrong

·         TraceLoggingHoloLensSensorsProvider.OnDeviceAdd

·         TraceLoggingOasisUsbHostApiProvider.DeviceInformation

For those of us few with a Mixed Reality device gathering dust on the desk, these events will inform Microsoft of information about any new device added or removed, information about the devices state in the Mixed Reality world, details on the Mixed Reality Portal App when used, how things went when you first used that app, and lots of details about the Mixed Reality Device regarding its bootloader, calibration, firmware, serial number, manufacturer etc.

Did this event occur in my 30 days’ worth of data?

No.

Given my lack of Windows Mixed Reality devices and unwillingness to load up the app for the sheer fun of it, I expected to find no events triggered and I was not thankfully shocked to find any.

 

Inventory Events

It won’t surprise many to find out that this group of events contains a lot of wonga for Microsoft events to get information about your device as there are 46 events in this group:

·         Microsoft.Windows.Inventory.Core.AmiTelCacheChecksum

·         Microsoft.Windows.Inventory.Core.InventoryAcpiPhatHealthRecordAdd

·         Microsoft.Windows.Inventory.Core.InventoryAcpiPhatHealthRecordStartSync

·         Microsoft.Windows.Inventory.Core.InventoryAcpiPhatVersionElementAdd

·         Microsoft.Windows.Inventory.Core.InventoryAcpiPhatVersionElementStartSync

·         Microsoft.Windows.Inventory.Core.InventoryApplicationAdd

·         Microsoft.Windows.Inventory.Core.InventoryApplicationFrameworkAdd

·         Microsoft.Windows.Inventory.Core.InventoryApplicationFrameworkStartSync

·         Microsoft.Windows.Inventory.Core.InventoryApplicationRemove

·         Microsoft.Windows.Inventory.Core.InventoryApplicationStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDeviceContainerAdd

·         Microsoft.Windows.Inventory.Core.InventoryDeviceContainerRemove

·         Microsoft.Windows.Inventory.Core.InventoryDeviceContainerStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDeviceInterfaceAdd

·         Microsoft.Windows.Inventory.Core.InventoryDeviceInterfaceStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDeviceMediaClassAdd

·         Microsoft.Windows.Inventory.Core.InventoryDeviceMediaClassRemove

·         Microsoft.Windows.Inventory.Core.InventoryDeviceMediaClassStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDevicePnpAdd

·         Microsoft.Windows.Inventory.Core.InventoryDevicePnpRemove

·         Microsoft.Windows.Inventory.Core.InventoryDevicePnpStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDeviceSensorAdd

·         Microsoft.Windows.Inventory.Core.InventoryDeviceSensorRemove

·         Microsoft.Windows.Inventory.Core.InventoryDeviceSensorStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDeviceUsbHubClassAdd

·         Microsoft.Windows.Inventory.Core.InventoryDeviceUsbHubClassStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDriverBinaryAdd

·         Microsoft.Windows.Inventory.Core.InventoryDriverBinaryRemove

·         Microsoft.Windows.Inventory.Core.InventoryDriverBinaryStartSync

·         Microsoft.Windows.Inventory.Core.InventoryDriverPackageAdd

·         Microsoft.Windows.Inventory.Core.InventoryDriverPackageRemove

·         Microsoft.Windows.Inventory.Core.InventoryDriverPackageStartSync

·         Microsoft.Windows.Inventory.General.AppHealthStaticAdd

·         Microsoft.Windows.Inventory.General.AppHealthStaticStartSync

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousMemorySlotArrayInfoAdd

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousMemorySlotArrayInfoRemove

·        Microsoft.Windows.Inventory.General.InventoryMiscellaneousMemorySlotArrayInfoStartSync

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousOfficeAddInAdd

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousOfficeAddInRemove

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousOfficeAddInStartSync

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoAdd

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoRemove

·         Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoStartSync

·         Microsoft.Windows.Inventory.Indicators.Checksum

·         Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorAdd

·         Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorRemove

·         Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorStartSync

 

I’m not going to attempt to go through each on in detail, but I’ll give a little idea of what goodies they contain. Microsoft.Windows.Inventory.Core.AmiTelCacheChecksum has a lot of fields but simply provides Microsoft with validation on any device inventory item stored in the cache on your device. The next four events concern the ACPI (Advanced Configuration and Power Interface, everyone’s favourite standard for operating systems to use to discover and configure hardware components and PHAT (Platform Health Assessment Table) which is somewhere else Microsoft can gain access to interesting data as this contains telemetry on firmware drivers executed prior to the OS starting up. There are events to tell Microsoft information on existing, and any additions or removal of: applications, monitors/printers, sensor interfaces, Plug in Play Device, USB Hubs, drivers, memory hardware, office add-ins, Unified Update Platform (UUP) products.

Did this event occur in my 30 days’ worth of data?

Yes.

Lots.

And far too much to go into extensive detail.

127	Microsoft.Windows.Inventory.Core.InventoryApplicationAdd
58	Microsoft.Windows.Inventory.Core.InventoryApplicationRemove
4	Microsoft.Windows.Inventory.Core.InventoryDeviceMediaClassRemove
22	Microsoft.Windows.Inventory.Core.InventoryDevicePnpAdd
47	Microsoft.Windows.Inventory.Core.InventoryDevicePnpRemove
2	Microsoft.Windows.Inventory.Core.InventoryDriverBinaryAdd
2	Microsoft.Windows.Inventory.Core.InventoryDriverBinaryRemove
1	Microsoft.Windows.Inventory.Core.InventoryDriverPackageAdd
50	Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoAdd
1	Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoStartSync
16	Microsoft.Windows.Inventory.Indicators.Checksum
35	Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorAdd
1	Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorStartSync

 

With the application add and removals, unlike other events, this does literally do what it says and records the installation and uninstall details. Here’s an install of Microsoft’s Web Experience software (via the store):

Microsoft.Windows.Inventory.Core.InventoryApplicationAdd

data":{"ProgramInstanceId":"0000da39a3ee5e6b4b0d3255bfef95601890afd80709","Name":"MicrosoftWindows.Client.WebExperience","Publisher":"CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US","Version":"421.20070.95.0","Language":2057,"Source":"AppxPackage","Type":"Application","StoreAppType":"CentennialStoreApp","HiddenArp":"false","PackageFullName":"MicrosoftWindows.Client.WebExperience_421.20070.95.0_x64__cw5n1h2txyewy","RootDirPath":"%ProgramFiles%\\windowsapps\\microsoftwindows.client.webexperience_421.20070.95.0_x64__cw5n1h2txyewy","baseType":"Ms.Device.DeviceInventoryChange","baseData":{"action":1,"objectType":"InventoryApplication","objectInstanceId":"000066f4876034e4b935a87c35c9dfa4488500000908","syncId":"{155de3d4-2e20-4d0c-816e-5a8e7fe81859}","inventoryId":"{57EF5FFC-0440-C870-FBE6-2FA81D17089D}"},"InventoryVersion":"10022000"}}

Microsoft.Windows.Inventory.Core.InventoryDevicePnpAdd

Someone might know more but I got a lot of the device events, and they all relate to Microsoft Streaming Clock Proxy:

"data": {

"HWID": [

{

"Value": "sw\{97ebaacc-95bd-11d0-a3ea-00a0c9223196}",

"Order": 0

}

],

"COMPID": [

],

"STACKID": [

{

"Value": "\driver\ksthunk",

"Order": 0

},

{

"Value": "\driver\mspclock",

"Order": 1

},

{

"Value": "\driver\swenum",

"Order": 2

}

],

"ExtendedInfs": [

],

"ProblemCode": "0",

"InstallState": "0",

"Enumerator": "sw",

"ContainerId": "{27db0821-3bf9-f71a-f96f-a53403857690}",

"DeviceState": "96",

"ParentId": "root\system\0000",

"Description": "Microsoft Streaming Clock Proxy",

"BusReportedDescription": "",

"MatchingID": "sw\{97ebaacc-95bd-11d0-a3ea-00a0c9223196}",

"Class": "media",

"ClassGuid": "{4d36e96c-e325-11ce-bfc1-08002be10318}",

"Manufacturer": "Microsoft",

"Model": "Microsoft Streaming Clock Proxy",

"Inf": "ksfilter.inf",

"DriverName": "mspclock.sys",

"DriverVerVersion": "10.0.22000.1",

"DriverVerDate": "06-21-2006",

"InstallDate": "07-03-2021",

"FirstInstallDate": "07-03-2021",

"Provider": "Microsoft",

"DriverPackageStrongName": "ksfilter.inf_amd64_d8f4d2dbd92f9d94",

"DriverId": "0000ed7934b178a053e8f0726952bc8fb5f432204d84",

"Service": "mspclock",

"LowerClassFilters": "",

"LowerFilters": "",

"UpperClassFilters": "ksthunk",

"UpperFilters": "",

"DeviceInterfaceClasses": [

],

"baseType": "Ms.Device.DeviceInventoryChange",

"baseData": {

"action": 1,

"objectType": "InventoryDevicePnp",

"objectInstanceId": "sw\{97ebaacc-95bd-11d0-a3ea-00a0c9223196}\{53172480-4791-11d0-a5d6-28db04c10000}",

"syncId": "{00510b9d-395e-4ee6-a999-758992d26920}",

"inventoryId": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}"

},

"InventoryVersion": "10022000"

}

}

 

Microsoft.Windows.Inventory.General.InventoryMiscellaneousUUPInfoAdd

 

"data": {

"Identifier": "DefenderSignature.amd64",

"Version": "1.367.1115.0",

"Source": "",

"PreviousVersion": "",

"LastActivatedVersion": "",

"baseType": "Ms.Device.DeviceInventoryChange",

"baseData": {

"action": 1,

"objectType": "InventoryMiscellaneousUUPInfo",

"objectInstanceId": "DefenderSignature.amd64",

"syncId": "{eec643c1-c60a-4dc1-975c-9a2d23bcd306}",

"inventoryId": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}"

}

}

 

Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorAdd

"data": {

"IndicatorValue": "132990800526853577",

"baseType": "Ms.Device.DeviceInventoryChange",

"baseData": {

"action": 1,

"objectType": "InventoryMiscellaneousUexIndicator",

"objectInstanceId": "GenTelRunTimestamp",

"syncId": "{3AF746D6-4F8B-402D-A24B-F5DBBB5A608E}",

"inventoryId": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}"

}

}

 

Microsoft.Windows.Inventory.Indicators.Checksum

"data": {

"PCFP": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}",

"ChecksumDictionary": {

"InventoryMiscellaneousUexIndicator": "1"

}

}

 

Microsoft.Windows.Inventory.Indicators.InventoryMiscellaneousUexIndicatorAdd

"data": {

"IndicatorValue": "132990800526853577",

"baseType": "Ms.Device.DeviceInventoryChange",

"baseData": {

"action": 1,

"objectType": "InventoryMiscellaneousUexIndicator",

"objectInstanceId": "GenTelRunTimestamp",

"syncId": "{3AF746D6-4F8B-402D-A24B-F5DBBB5A608E}",

"inventoryId": "{57EF5FFC-0440-C870-FBE6-2FA81D17089D}"

}

}

 

Kernel Events

It says Kernel but this group covers different aspects from Plug and Play Devices and Power issues:

 

·         Microsoft.Windows.Kernel.DeviceConfig.DeviceConfig

·         Microsoft.Windows.Kernel.PnP.AggregateClearDevNodeProblem

·         Microsoft.Windows.Kernel.PnP.AggregateSetDevNodeProblem

·         Microsoft.Windows.Kernel.Power.ExecutePowerAction

·         Microsoft.Windows.Kernel.Power.PreviousShutdownWasThermalShutdown

 

DeviceConfig.DeviceConfig reports on driver installs that happen within the kernel and reports back all the same kind of data from the Driver Installation Events previously discussed. The Two PnPs events are about “problem codes” that occur in devices and literally send back limited data about what the code was, when it occurred, and what service or driver had the problem. Power.ExecutePowerAction is all about “power state transition parameters“ of which I can’t make head or tails out of the documentation exactly what data it sends back on these. But I can say the last event PreviousShutdownWasThermalShutdown reports back the temperature (in degrees of Kelvin) and the area of the device that overheated.

Did this event occur in my 30 days’ worth of data?

Yes.

Only the four DeviceConfig events happened, well spread out over the 30 days. I certainly don’t recall installing drivers 4 times in 30 days but it’s not impossible. I can’t find anything in the event logs that help explain matters. Here’s the data from one of the events:

data":{"Legacy":false,"DeviceInstanceId":"SWD\\PRINTENUM\\{530ACD2B-CC78-4537-B9F8-90EE212343ED}","FirstHardwareId":"PRINTENUM\\{3ee39114-30b4-45a4-a109-19d4a40fcc22}","LastCompatibleId":"SWD\\Generic","ClassGuid":"{1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}","DriverInfName":"printqueue.inf","DriverProvider":"Microsoft","DriverDate":"06/21/2006","DriverVersion":"10.0.22000.1","InboxDriver":1,"SetupMode":0,"NeedReboot":0,"RebootRequiredReason":0,"StatusCode":0,"InstallDate":"2022-03-10T15:24:55.7781599Z"}}

Both the PnP events happened 9 times each and at the same times as each other so clearly these two events are linked but once again I can’t find anything in the event logs that helps tell me what triggered these events.

data":{"Count":1,"DeviceInstanceId":"PCI\\VEN_8086&DEV_0083&SUBSYS_13258086&REV_00\\4&14670f07&0&00E1","ServiceName":"NETwNs64","Problem":21,"ProblemStatus":0,"LastProblem":0,"LastProblemStatus":0}}

Manufacturing Events

There are 4 types of manufacturing events documented by Microsoft that your device will report back which are:

 

·         ManufacturingPlatformTel.ManufacturingPlatformActivityEvent

·         ManufacturingPlatformTel.ManufacturingPlatformEventStart

·         ManufacturingPlatformTel.ManufacturingPlatformEventStop

·         ManufacturingPlatformTel.ManufacturingPlatformEvent

The documentation on these events lists all the types of data that can be reported from those 4 events but of course as ever fails to make it implicitly clear to the layperson what the heck this means. My best bet is that this is another OOBE and OEM-related kind of telemetry, sorry diagnostic data, that will inform Microsoft of how well a Windows 11 image was deployed on a device.

Did this event occur in my 30 days’ worth of data?

No

Unsurprisingly, no, given my 30 days was not during the initial setup of my device or any significant image installation like if I’d installed a Windows 11 build via an ISO.

 

Microsoft Edge Events

You’ll not be surprised to find Microsoft sneaked Microsoft Edge into required diagnostics. Of course, they did. They want their browser to succeed and given it’s bundled onto all Windows 11 devices by default and integrated into components of Windows that you can’t stop it from being used for (Widgets and Search) any diagnostics on its handling in this respect is useful to them. If we can’t stop Edge from being used for these components, then I think we’d all like it to work fluidly when it does fire up, and thus we can see the logic in them finding out how their browser is performing.

For reasons known only to Microsoft, the events associated with this group have the weirdest names out of everything I’m blogging about here:

·         Aria.160f0649efde47b7832f05ed000fc453.Microsoft.WebBrowser.SystemInfo.Config

·         Aria.29e24d069f27450385c7acaa2f07e277.Microsoft.WebBrowser.SystemInfo.Config

·         Aria.7005b72804a64fa4b2138faab88f877b.Microsoft.WebBrowser.SystemInfo.Config

·         Aria.754de735ccd546b28d0bfca8ac52c3de.Microsoft.WebBrowser.SystemInfo.Config

·        Aria.af397ef28e484961ba48646a5d38cf54.Microsoft.WebBrowser.Installer.EdgeUpdate.Ping

As you can see, there are five events under this umbrella, and they all start with Aria, then a lovely memorable gobbledegook GUID (one assumes) name, and then the commonly spoken word that most of us understand, English. Nice.

Of course, everyone’s first question is, ‘why are there 4 events with the same words but different GUIDS?’. Good question. No idea. There’s no difference that I can see in the data fields in either of these 4 events so I can only suspect that it might be related to versions of the browser, but it seems odd given nothing else is so hung up on different names for different versions of anything.

Each of the Systeminfo.config events Microsoft say collects “basic device connectivity and configuration information from Microsoft Edge about the current data collection consent, app version, and installation state“. Data collected includes the obvious, like the edge build version and channel but also your device’s client ID, sampling rate set, connection type, Information about WDAG mode, when this version of Edge was installed and where it was installed from.

1	Aria.160f0649efde47b7832f05ed000fc453.Microsoft.WebBrowser.SystemInfo.Config
42	Aria.6660cc65b74b4291b30536aea7ed6ead.Microsoft.WebBrowser.SystemInfo.Config
13	Aria.7005b72804a64fa4b2138faab88f877b.Microsoft.WebBrowser.SystemInfo.Config
229	Aria.af397ef28e484961ba48646a5d38cf54.Microsoft.WebBrowser.Installer.EdgeUpdate.Ping

 

What I can deduce by monitoring the Diagnostic Data Viewer as I use areas of Edge in Windows 11 and by deduction from the content of the data in the events is that:

Aria.7005b72804a64fa4b2138faab88f877b.Microsoft.WebBrowser.SystemInfo.Config seems to related to the current installation of Edge Browser.

Aria.6660cc65b74b4291b30536aea7ed6ead.Microsoft.WebBrowser.SystemInfo.Config is related to msedgewebview2.exe which is normally related to the Widgets.

Aria.af397ef28e484961ba48646a5d38cf54.Microsoft.WebBrowser.Installer.EdgeUpdate.Ping is related to the Edge Update Program we all have installed.

However, the first event above I don’t know what it was, and it’s not occurred since, but I used to have Edge Canary Browser installed so it might be related to that.

Aria.160f0649efde47b7832f05ed000fc453.Microsoft.WebBrowser.SystemInfo.Config

 

data":{"Channel":1,"Etag":"\"YfZrApEDUSfDWllVw0VhZ9f3CcPT/30MzY+Kq5j9J3E=\"","EventInfo.Level":1,"PayloadClass":"SYSTEM_INFO","PayloadGUID":"2a3d7852-87fa-468c-8c7e-4cdcb84a6b18","PayloadLogType":5,"AppSessionGuid":"0000382C-000B-004C-522F-2A4E1920D801","appConsentState":524288,"app_sample_rate":15.766999999999999,"app_version":"100.0.1160.0-64","brandCode":"GGLS","client_id":-7682959538226379100,"device_sample_rate":71.477999999999994,"experimentation_mode":-1,"installSourceName":"taggedmi","install_date":1622383200,"pop_sample":100,"reactivationBrandCode":"RegKeyNotFound","session_id":129,"utc_flags":140737488879616}}

 

Aria.6660cc65b74b4291b30536aea7ed6ead.Microsoft.WebBrowser.SystemInfo.Config

 

"data": {

"Channel": 4,

"Etag": "\"TPT6EtYS2ttHv9yxNOVh6FEs3CNrOBNCc5j1YeKAPDY=\"",

"EventInfo.Level": 1,

"PayloadClass": "SYSTEM_INFO",

"PayloadGUID": "7b14b50c-84b6-4bee-85eb-34672294eff9",

"PayloadLogType": 5,

"AppSessionGuid": "00000FEC-0007-005E-4FD2-707B2778D801",

"appConsentState": 8,

"app_sample_rate": 91.034000000000006,

"app_version": "101.0.1210.53-64",

"brandCode": "INBX",

"client_id": -1200098344883223770,

"device_sample_rate": 71.477999999999994,

"experimentation_mode": -1,

"installSourceName": "windows",

"install_date": 1625310000,

"pop_sample": 100,

"reactivationBrandCode": "RegKeyNotFound",

"session_id": 206,

"utc_flags": 140737488879616

}

}

 

Aria.7005b72804a64fa4b2138faab88f877b.Microsoft.WebBrowser.SystemInfo.Config

 

"data": {

"Channel": 4,

"Etag": "\"V9z71VMEZo3Hb/322QdEKDJDdgjWgyOJDKzQqWpCHgQ=\"",

"EventInfo.Level": 1,

"PayloadClass": "SYSTEM_INFO",

"PayloadGUID": "eb603903-3619-4ed6-ad08-62c91a06d46f",

"PayloadLogType": 5,

"AppSessionGuid": "00002FAC-0007-005E-AECC-C7CF2778D801",

"appConsentState": 524288,

"app_sample_rate": 13.476000000000001,

"app_version": "101.0.1210.53-64",

"brandCode": "INBX",

"client_id": -2079428931129718724,

"device_sample_rate": 71.477999999999994,

"experimentation_mode": -1,

"installSourceName": "windows",

"install_date": 1621090800,

"pop_sample": 100,

"reactivationBrandCode": "RegKeyNotFound",

"session_id": 413,

"utc_flags": 140737488879616

}

}

 

Aria.af397ef28e484961ba48646a5d38cf54.Microsoft.WebBrowser.Installer.EdgeUpdate.Ping

 

"data": {

"EventInfo.Level": 1,

"appAp": "",

"appAppId": "{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}",

"appBrandCode": "INBX",

"appChannel": 4,

"appClientId": "",

"appCohort": "rrf@0.87",

"appCohortHint": "",

"appCohortName": "",

"appConsentState": 0,

"appDayOfInstall": 0,

"appExperiments": "consent=false",

"appFirstFRESeenTime": 0,

"appFirstFRESeenVersion": "",

"appInstallTime": 0,

"appInstallTimeDiffSec": 0,

"appLang": "",

"appLastLaunchTime": 13298755814311165,

"appNextVersion": "102.0.1245.30",

"appOOBEInstallTime": 0,

"appPingEventAppSize": 0,

"appPingEventDoneBeforeOOBEComplete": 0,

"appPingEventDownloadMetricsCdnAzureRefOriginShield": "",

"appPingEventDownloadMetricsCdnCCC": "",

"appPingEventDownloadMetricsCdnCID": -1,

"appPingEventDownloadMetricsCdnCache": "",

"appPingEventDownloadMetricsCdnMSEdgeRef": "",

"appPingEventDownloadMetricsCdnP3P": "",

"appPingEventDownloadMetricsDownloadTimeMs": 0,

"appPingEventDownloadMetricsDownloadedBytes": 0,

"appPingEventDownloadMetricsDownloader": 0,

"appPingEventDownloadMetricsError": 0,

"appPingEventDownloadMetricsServerIpHint": "",

"appPingEventDownloadMetricsTotalBytes": 0,

"appPingEventDownloadMetricsUrl": "",

"appPingEventDownloadTimeMs": 0,

"appPingEventErrorCode": 0,

"appPingEventEventResult": 1,

"appPingEventEventType": 12,

"appPingEventExtraCode1": 0,

"appPingEventInstallTimeMs": 0,

"appPingEventNumBytesDownloaded": 0,

"appPingEventPackageCacheResult": -1,

"appPingEventSequenceId": 1,

"appPingEventSourceUrlIndex": -1,

"appPingEventUpdateCheckTimeMs": 0,

"appReferralHash": 0,

"appUpdateCheckIsRollbackAllowed": 0,

"appUpdateCheckIsUpdateDisabled": 0,

"appUpdateCheckTargetChannel": "",

"appUpdateCheckTargetVersionPrefix": "",

"appUpdateCheckTtToken": "",

"appUpdateCount": 2,

"appVersion": "101.0.1210.53",

"eventType": "EVENT_UPDATE_APPLICATION_BEGIN",

"expETag": "\"r452t1+k2Tgq/HXzjvFNBRhopBWR9sbjXxqeUDH9uX0=\"",

"hwDiskType": 2,

"hwHasAvx": 1,

"hwHasSse": 1,

"hwHasSse2": 1,

"hwHasSse3": 1,

"hwHasSse41": 1,

"hwHasSse42": 1,

"hwHasSsse3": 1,

"hwLogicalCpus": 4,

"hwPhysmemory": 6,

"isMsftDomainJoined": 0,

"oemProductManufacturer": "Dell Inc.",

"oemProductName": "Dell System XPS L702X",

"osArch": "x64",

"osPlatform": "win",

"osServicePack": "",

"osVersion": "10.0.22000.675",

"requestCheckPeriodSec": -1,

"requestDlpref": "",

"requestDomainJoined": 0,

"requestInstallSource": "scheduler",

"requestIsMachine": 1,

"requestOmahaShellVersion": "1.3.141.63",

"requestOmahaVersion": "1.3.161.35",

"requestProtocolVersion": "3.0",

"requestRequestId": "{920133F7-9EE8-487C-8733-5B2212E24C14}",

"requestSessionCorrelationVectorBase": "k/Y71npEPkmQuU3rP9W4Tw",

"requestSessionId": "{D63BF693-447A-493E-90B9-4DEB3FD5B84F}",

"requestTestSource": "",

"requestUid": "{A6530714-1611-4698-945D-231EA102E73D}"

}

}

 

Aria.7005b72804a64fa4b2138faab88f877b.Microsoft.WebBrowser.SystemInfo.Config

 

"data": {

"Channel": 4,

"Etag": "\"752/0xpcbQTqrciqApuF9DNoe311ISpMQQ9SgBwMGGU=\"",

"EventInfo.Level": 1,

"PayloadClass": "SYSTEM_INFO",

"PayloadGUID": "930bc1b8-17aa-488b-a42b-62e364d97358",

"PayloadLogType": 5,

"AppSessionGuid": "00003634-0004-005E-899D-6AFD4877D801",

"appConsentState": 524288,

"app_sample_rate": 13.476000000000001,

"app_version": "101.0.1210.53-64",

"brandCode": "INBX",

"client_id": -2079428931129718724,

"device_sample_rate": 71.477999999999994,

"experimentation_mode": -1,

"installSourceName": "windows",

"install_date": 1621090800,

"pop_sample": 100,

"reactivationBrandCode": "RegKeyNotFound",

"session_id": 409,

"utc_flags": 140737488879616

}

 

Migration Events

No, nothing to do with birds, but instead all to do with feature updates. Presumably, it’s to do with the migration of user data during the upgrade part of a feature update. The documentation says, “This event returns data to track the count of the migration objects across various phases during feature update.”

There are a mere three events in this group:

·         Microsoft.Windows.MigrationCore.MigObjectCountDLUsr

·         Microsoft.Windows.MigrationCore.MigObjectCountKFSys

·         Microsoft.Windows.MigrationCore.MigObjectCountKFUsr

 

The data fields involved in the above are few and far between, and merely capture user ISD, the phase of the upgrade where migration happens, a count of objects being transferred and predefined folder path locations.

Did this event occur in my 30 days’ worth of data?

No

Given the distinct lack of Windows Feature Updates for Windows 11 at the time of writing it’s not unexpected that I had none of these events.

 

OneSettings Events

Now we come to the exciting stuff. Nah, only joking. I’m just trying to make this all sound more interesting but it’s hard to keep one’s attention up when the information supplied by Microsoft can be so dry and vague.

Within the OneSettings events there are three types of events:

·         Microsoft.Windows.OneSettingsClient.Heartbeat

·         Microsoft.Windows.OneSettingsClient.StateChange

·         Microsoft.Windows.OneSettingsClient.Status

As to any more clearer information on what OneSettings is, I don’t know. Even a Google Search is vague. This reminds me somewhat of OneCore which was a single binary of Windows Core files which I cannot recall if it ever reached the level they wanted it to. So, we can assume that this might be a single settings binary? Goodness knows. Given there are very little data attached to a StateChange or Status event I’m unsure how much use this data is to Microsoft, but hey, they know best right?

Did this event occur in my 30 days’ worth of data?

Yes

Every day there’s a heartbeat event for OneSettings. Well, it occurred 38 times so that might be related to when my computer went to sleep or restarted after an update that the heartbeat kicked back in.

 

 

OOBE Events

Now, this title is a bit more self-explanatory than most. We all know that OOBE is the out-of-box experience stuff, so this happens when a user first turns on a device and goes through all that setup rigmarole. However, there are four types of events in this category, and they all have a prefixed title of ExpeditedUpdate which is interesting. Is this still the “normal” first-time OOBE or something else? Each of the types of events below have very little data fields sent back and are really just simple result codes to report if any of this failed or succeeded.

·         Microsoft.Windows.Shell.Oobe.ExpeditedUpdate.ExpeditedUpdate.ChoiceCommitted

·         Microsoft.Windows.Shell.Oobe.ExpeditedUpdate.ExpeditedUpdate.PageSkipped

·         Microsoft.Windows.Shell.Oobe.ExpeditedUpdate.ExpeditedUpdate.StartUSOScan

·         Microsoft.Windows.Shell.Oobe.ExpeditedUpdate.ExpeditedUpdate.UpdateStatusResult

Now, there are such things as expediated updates in the Windows World that business customers using Azure or InTune can customise etc. Is this related to that? Most probably as a USO is a Windows Update Scan so my best guess is that’s what these types of data are used for.  

Did this event occur in my 30 days’ worth of data?

No.

This is expected given my device isn’t a business device in any way, although it is a Pro version of Windows 11.

 

Privacy consent logging events

Microsoft hypes the privacy features in Windows 11 and thus it stands to reason they’d want to find out what the users are up to when it comes to privacy settings. Some might say this sounds somewhat contradictory to being strong on privacy but also “snooping” to see what everyone likes to select for privacy settings, especially as we can’t turn off the required diagnostic data. Not me though, no, I wouldn’t say that.

What I would say is that there are two fields in this group:

·         Microsoft.Windows.Shell.PrivacyConsentLogging.PrivacyConsentCompleted

·         Microsoft.Windows.Shell.PrivacyConsentLogging.PrivacyConsentStatus

The first event is focused by the looks of it with the blue consent screen window we all get in Windows 11 periodically for it’s interested in general data about when the user has performed this experience whereas the latter event is slightly more focussed on the user who performs the privacy window function as it’s interested in if the user is an admin and their region code amongst a few other basic data about the privacy window. What amuses me slightly is that for both these events the documentation says that they help keep windows up to date which I’m not sure exactly how whether a user has chosen certain privacy settings helps with that as the user is presumably allowed to have whatever privacy settings they want?

Did this event occur in my 30 days’ worth of data?

No.

I didn’t have the privacy window screen during these 30 days, so, zilch.

 

Servicing API Events

I’m not expecting to get much enlightenment here and true to form I don’t get much from the documentation. The two events in this area are:

·         Microsoft.Windows.ServicingUAPI.ModifyFeaturesEnd

·         Microsoft.Windows.ServicingUAPI.ModifyFeaturesResult

It seems from the information that’s there that this is once again related to a Windows feature and changes to them although it’s still unclear as before if “feature” means the kind we get in Windows Updates or a sub aspect of the Windows OS. There is some human wording in this documentation though whereby it says these events are related to “Software Setup and Inventory data” which gives us something to narrow in on but it’s still all rather vague.

Did this event occur in my 30 days’ worth of data?

No.

 

Setup Events

Yet another group of events related to upgrades happening, so, I think you can guess what actual data I might have retrieved on this during my 30 days …

There are 9 events, with the first five being about the windows setup boot experience when a feature update (and presumably a significant one) happens as there’s a reference to the upgrade rolling back being reported in these events if it occurred whereas the next 4 send back “basic metadata" by the SetUpPlatform which is apparently the engine that drives deployment scenarios.

·         Microsoft.Windows.Setup.WinSetupBoot.BootBlockStart

·         Microsoft.Windows.Setup.WinSetupBoot.BootBlockStop

·         Microsoft.Windows.Setup.WinSetupBoot.Success

·         Microsoft.Windows.Setup.WinSetupBoot.Warning

·         Microsoft.Windows.Setup.WinSetupMon.ProtectionViolation

·         SetupPlatformTel.SetupPlatformTelActivityEvent

·         SetupPlatformTel.SetupPlatformTelActivityStarted

·         SetupPlatformTel.SetupPlatformTelActivityStopped

·         SetupPlatformTel.SetupPlatformTelEvent

Did this event occur in my 30 days’ worth of data?

No.

No significant upgrades, no data!

 

SIH Events

What’s SIH? Well, it’s all related to Microsoft Updates again as this stands for “Silent Install Helper” and is related to the background install of updates and all helps detect and fix problems related to installing updates. Given my background in IT and the documentation, this is one of the clearer types of events so far, especially given the two types of events that can be trigger for SIH:

·         SIHEngineTelemetry.EvalApplicability

·         SIHEngineTelemetry.ExecuteAction

These two are triggered in the order above as the first one reports if an update was applicable to the device and the second one reports the result of the update installation to Microsoft.

All the various data fields associated with these events relate to the Windows Update Client and update process so there’s clearly only a particular reason for the SIH Events to be triggered into action here and it’s not related to any Windows Update because …

Did this event occur in my 30 days’ worth of data?

No.

This is a little surprising as I did have several Windows Updates during those 30 days. However, as we’ll see later, update telemetry (sorry, diagnostic data) comes under a different event name.

 

Software update events

If there was any type of event that you’d think Microsoft would want to throttle your device for telemetry from, sorry – diagnostic data, then it’s software updates. There’s a perception and a stigma about the “Please wait whilst your computer updates” stuff in Windows, not least that we’ve all at some point experienced a dud of an update that has ever sent our computer into an update loop, totally jiggered us, or just simply kept failing. Thankfully, for the most part, such an occurrence is low, but it happens, and Microsoft need to be on top of this, so naturally, they are getting everything they can on this process from our devices.

There are eleven types of events in this grouping:

·         SoftwareUpdateClientTelemetry.CheckForUpdates

·         SoftwareUpdateClientTelemetry.Commit

·         SoftwareUpdateClientTelemetry.Download

·         SoftwareUpdateClientTelemetry.DownloadCheckpoint

·         SoftwareUpdateClientTelemetry.DownloadHeartbeat

·         SoftwareUpdateClientTelemetry.Install

·         SoftwareUpdateClientTelemetry.Revert

·         SoftwareUpdateClientTelemetry.TaskRun

·         SoftwareUpdateClientTelemetry.Uninstall

·         SoftwareUpdateClientTelemetry.UpdateDetected

·        SoftwareUpdateClientTelemetry.UpdateMetadataIntegrity

 

A lot of the above is self-explanatory I’d say but it’s worth a little clarity especially when you see the numbers below of how frequently they all occurred on my device. The CheckForUpdates event contains a lot of data fields from the servicing branch, software distribution client vision, what updates are being deferred (interesting – presumably this is paused updates but that’s implicitly mentioned later), info on any failures, Feature Update figures on deferrals and pauses, applicable updates, type of network connectivity (IP4 or 6), Lots of paused data such as start and end times, how long the scan took and more; it’s quite comprehensive. The Commit is apparently more focused on an upgrade, Download is as you’d expect all about time taken to download an update, the number of bytes downloaded, name of update, etc, DownloadCheckpoint is about checkpoints between download phases related specifically to Unified update platform (UUP), DownloadHeartbeat tracks ongoing downloads of updates, Install is quite meaty with lots of data about the installation, Revert is also meaty and narrows in on when updates have to roll back (I assume from what I’m reading), TaskRun is specific about the SIHC Client (Server Initiated Healing Client), Uninstall is, well, when an update is uninstalled, UpdateDetected is saying is specifically about updates in the Microsoft Store and then only about when updates are found and UpdateMetadataIntegrity focuses only on helping prevent any man-in-the-middle attacks to ensure the update content has not been tampered with.

Did this event occur in my 30 days’ worth of data?

Yes.

No day goes by without a Windows Update in some form huh? Not least a Windows Defender Definition Update at the very least, so therefore, I got a lot of events in this group during 30 days.

 

246	SoftwareUpdateClientTelemetry.CheckForUpdates
205	SoftwareUpdateClientTelemetry.Download
4	SoftwareUpdateClientTelemetry.DownloadCheckpoint
93	SoftwareUpdateClientTelemetry.Install
52	SoftwareUpdateClientTelemetry.TaskRun
88	SoftwareUpdateClientTelemetry.UpdateDetected
114	SoftwareUpdateClientTelemetry.UpdateMetadataIntegrity

 

CheckForUpdates occurred multiple times every day, as anyone with Windows 11 or 10 will know it seems to just run all the time whenever one opens Settings. It’s an absolutely beast of data as you can see below:

"data": {

"EventScenario": "Succeeded",

"EventInstanceID": "2656F915-862D-47AB-ADD5-D346CF617C1A",

"ClientVersion": "10.0.22000.653",

"WUDeviceID": "a60e8734-aeab-483e-95a4-1343e78bb7bc",

"CallerApplicationName": "Update;",

"ProcessName": "",

"ServiceGuid": "855E8A7C-ECB4-4CA3-B045-1DFA50104289",

"RelatedCV": "",

"IsWUfBEnabled": 0,

"IsWUfBDualScanEnabled": 0,

"QualityUpdatePause": -1,

"FeatureUpdatePause": -1,

"IsWUfBTargetVersionEnabled": 0,

"CommonProps": 0,

"StatusCode": 0,

"ExtendedStatusCode": 0,

"ActivityMatchingId": "31FB2D0B-35BF-4007-831C-869E33629ECE",

"SyncType": 4,

"IPVersion": 1,

"NumberOfApplicationsCategoryScanEvaluated": 1,

"ScanDurationInSeconds": 3,

"ScanEnqueueTime": 0,

"NumberOfLoop": 1,

"NumberOfUpdatesEvaluated": 240,

"NumberOfNewUpdatesFromServiceSync": 0,

"ServiceUrl": "https://fe3cr.delivery.mp.microsoft.com/ClientWebService/client.asmx",

"Online": true,

"AllowCachedResults": false,

"MetadataIntegrityMode": 3,

"TotalNumMetadataSignatures": 0,

"NumFailedMetadataSignatures": 0,

"DriverSyncPassPerformed": 0,

"ScanProps": 1,

"NumberOfApplicableUpdates": 0,

"ApplicableUpdateInfo": "",

"WebServiceRetryMethods": 0,

"DeferredUpdates": "",

"PausedUpdates": "",

"BranchReadinessLevel": "CB",

"DeferralPolicySources": -1,

"QualityUpdateDeferral": -1,

"PauseQualityUpdatesStartTime": "",

"PauseQualityUpdatesEndTime": "",

"QualityUpdatePausePeriod": 0,

"FeatureUpdateDeferral": -1,

"PauseFeatureUpdatesStartTime": "",

"PauseFeatureUpdatesEndTime": "",

"FeatureUpdatePausePeriod": 0,

"DriverExclusionPolicy": -1,

"TargetProductVersion": "",

"TargetReleaseVersion": "",

"ExcludedUpdateClasses": "",

"ExcludedUpdates": "",

"IntentPFNs": "",

"UusVersion": "121.511.1.0"

}

}

 

A large number of events in these 30 days is mostly due to me using Windows Defender, sorry Windows Security (or just insert whatever name Microsoft are calling it at the time). There’s a definition update most days, which is, of course, a good thing. The large number of updates installed in 30 days (93) might seem quite high, given even with a definition update every day and one patch Tuesday, you’d might expect the figure to be in the 40s, although looking at the data, it appears that even the one update install can generate sometimes two of these events.

 

 

Surface events

Nope, this isn’t anything to do with coffee slippage or all that dust in-between keys on your laptop’s surface, but instead it’s about Microsoft’s Surface laptops. Yes, if you’ve got one of these devices on Windows 11, Microsoft is collecting specific data automatically about this device from you.

There are 7 events, and it looks like out of everything Microsoft is concerned about with your laptops, it’s the battery:

·         Microsoft.Surface.Battery.Prod.BatteryInfoEvent

·         Microsoft.Surface.Battery.Prod.BatteryInfoEventV2_BPM

·         Microsoft.Surface.Battery.Prod.BatteryInfoEventV2_CTT

·         Microsoft.Surface.Battery.Prod.BatteryInfoEventV2_GG

·        Microsoft.Surface.Battery.Prod.BatteryInfoEventV2_GGExt

·         Microsoft.Surface.Health.Binary.Prod.McuHealthLog

·         Microsoft.Surface.SystemReset.Prod.ResetCauseEventV2

 

The Battery events are collecting a shed load of data about the battery performance and charging such as what’s the full charge capacity, when was it charged, what’s battery limit, discharge current and more. The Binary.Prod event is looking specifically at the built-in microcontroller, especially “the number of abnormal shutdowns due to power issues during boot sequence, type of display panel attached to base, thermal indicator, throttling data in hardware etc.“ whereas the SystemReset event is looking to see if you’ve done a SAM, PCH or SoC reset on your surface device which is probably depending on if it was a soft or hard reset you used.

Did this event occur in my 30 days’ worth of data?

No.

If they did, I’d have really been surprised!

UEFI Events

The final new kid on the block event for Windows 11 has a clear title thankfully and only one type of event related to it, which is:

·         Microsoft.Windows.UEFI.ESRT

The documentation is also quite clear, which makes a refreshing change. This event is triggered during the boot-up of a device and reports back information on the firmware of the device and any that was recently loaded.

There is a shed load of fields related to this event all about the UEFI (aka modern BIOS) to tell Microsoft if the firmware failed, succeeded and its version etc.

Did this event occur in my 30 days’ worth of data?

No.

Not only did I do no firmware update in those 30 days, but I’ve also got the old-fashioned BIOS so I’m unsure if this event would be triggered by any firmware update and I’m not game enough to do any tests.

 

Update Assistant events

Thankfully, no Clippy in sight here. “It looks like you’re trying to install an Update, can I help?” Err, no. There’s none of that. Yippee. Instead, we’ve a strange bunch of 4 events grouped together here:

·         Microsoft.Windows.RecommendedTroubleshootingService.MitigationFailed

·         Microsoft.Windows.RecommendedTroubleshootingService.MitigationSucceeded

·         Microsoft.Windows.UpdateHealthTools.UpdateHealthToolsDeviceInformationUploaded

·         Microsoft.Windows.UpdateHealthTools.UpdateHealthToolsServiceIsDSSJoin

As the name suggests, the first two are related to the Mitigation Service which has a nice long explanation in the documentation, but I’m confused if this is external mitigation or a mitigation taken by an update itself? You’d assume the latter, right? Yet, the documentation for the MitigationSucceeded event says “This event is raised after an executable delivered by Mitigation Service has successfully run. Data from this event is used to measure the health of mitigations used by engineers to solve in-market problems on internal, insider, and retail devices.“ So the jury is out on if this is something automatic that’s delivered by updates or something Microsoft instigates especially as there are two data fields with the word “experiment” in it.

The Two events about UpdateHealthTools relate to Microsoft Update Health Tools (MUHT) which have been around for a while and “requests devices stay awake longer to complete the Windows updates/patches. It also helps reset the network settings to resolve issues if there is an issue.”

Did this event occur in my 30 days’ worth of data?

No.

However … in relation to my later section on WTF events (events that occurred that are not documented), I did get two events of the following name Microsoft.Windows.UpdateHealthTools.UnifiedInstallerEnd which happened on two separate occasions during the 30 days, separated by a decent number of days, and both during periods of Windows Updates being installed. One of these events contains the following data:

data":{"PackageVersion":"2022.03","GlobalEventCounter":6,"CV":"2YJSS74+Hk+Im9pH.0","UnifiedInstallerPlatformResult":0,"UnifiedInstallerPlatformType":1,"UnifiedInstallerInstallResult":0}}

The datestamps for the above two events are during updates, but they don’t match up exactly with an update finishing so maybe this is an update to the Update Health Tools?

Update events

You’d think this was all about software updates, right? And you’d be right except that there’s a strong emphasis in the documentation about UUP updates. Yes, those Unified update platform updates, which we know from previous event data, aren’t every update that’s installed but a smaller number. Intriguingly, in an ever-growing list of bizarrely named telemetry, sorry, diagnostic data, field names, this group of events all start with Update360Telemtry:

·         Update360Telemetry.DriverUpdateSummaryReport

·         Update360Telemetry.Revert

·         Update360Telemetry.UpdateAgentCommit

·         Update360Telemetry.UpdateAgentDownloadRequest

·         Update360Telemetry.UpdateAgentExpand

·         Update360Telemetry.UpdateAgentInitialize

·         Update360Telemetry.UpdateAgentInstall

·         Update360Telemetry.UpdateAgentMitigationResult

·         Update360Telemetry.UpdateAgentMitigationSummary

·         Update360Telemetry.UpdateAgentModeStart

·         Update360Telemetry.UpdateAgentOneSettings

·         Update360Telemetry.UpdateAgentPostRebootResult

·         Update360Telemetry.UpdateAgentReboot

·         Update360Telemetry.UpdateAgentSetupBoxLaunch

The documentation says that the DriverUpdateSummaryReport event “This event collects information regarding the state of devices and drivers on the system, following a reboot, after the install phase of the new device manifest UUP (Unified Update Platform) update scenario, which is used to install a device manifest describing a set of driver packages.”, Revert is literally sending a small about of data to Microsoft HQ during this phase of an update, UpdateAgentCommit is all about the commit page of an update, UpdateAgentDownloadRequest sends a truckload of data about various download sizes and package counts amongst other data during any UUP download request, UpdateAgentExpand is, yes, you guessed it, about the expansion phase of an UUP update, UpdateAgentInitialize is, yes, you know, UpdateAgentInstall is yes, that, UpdateAgentMitigationResult and UpdateAgentMitigationSummary reports on mitigation data during the update, and the rest really speak for themselves by this point. None of the events are full of data fields aside from the download one.

Did this event occur in my 30 days’ worth of data?

Yes.

·         12           Update360Telemetry.UpdateAgentDownloadRequest

·         5              Update360Telemetry.UpdateAgentExpand

·         31           Update360Telemetry.UpdateAgentInitialize

·         10           Update360Telemetry.UpdateAgentInstall

·         30           Update360Telemetry.UpdateAgentMitigationResult

·         10           Update360Telemetry.UpdateAgentMitigationSummary

·         52           Update360Telemetry.UpdateAgentModeStart

·         35           Update360Telemetry.UpdateAgentOneSettings

·         6              Update360Telemetry.UpdateAgentPostRebootResult

Upgrade events

As you may expect, Microsoft wants to know how well upgrades perform, as we’ve all experienced a little trepidation during an OS update and probably experienced some wobbles in this process.

To this end, there’s several events in this group:

·         FacilitatorTelemetry.DCATDownload

·         FacilitatorTelemetry.DUDownload

·         FacilitatorTelemetry.InitializeDU

·         Setup360Telemetry.Downlevel

·         Setup360Telemetry.Finalize

·         Setup360Telemetry.OsUninstall

·         Setup360Telemetry.PostRebootInstall

·         Setup360Telemetry.PreDownloadQuiet

·         Setup360Telemetry.PreDownloadUX

·         Setup360Telemetry.PreInstallQuiet

·         Setup360Telemetry.PreInstallUX

·         Setup360Telemetry.Setup360

·         Setup360Telemetry.Setup360DynamicUpdate

·         Setup360Telemetry.Setup360MitigationResult

·         Setup360Telemetry.Setup360MitigationSummary

·         Setup360Telemetry.Setup360OneSettings

·         Setup360Telemetry.UnexpectedEvent

The first three are interesting, what with the name FaciltiorTelemetry which I admit I’m unsure what it’s all about but the use of DCAT in some of the data fields suggests some sort of delivery catalogue and it seems to be about supplemental packages critical to an update, and as we know, there’s usually prerequisites to some updates so I’m guessing this is where anything else required before an upgrade starts is installed. Every other event is specific to the OS upgrade process. The final event UnexpectedEvent is when something unexpected happens, so, probably an OMG heart-in-mouth error.

Did this event occur in my 30 days’ worth of data?

No.

No Windows 11 Upgrades yet, so, no data.

 

 

Windows as a Service diagnostic events

Ahh, the old Windows as a service chestnut. Feels like we’ve heard this a lot since Windows 10 arrived. Well, there are only two events in this group and they really are only interested in the Windows as a Service Medic Agent which “Enables remediation and protection of Windows Update components.” Which is essentially fixing any issues with Windows Update so updates can install successfully.

·         Microsoft.Windows.WaaSMedic.StackDataResetPerformAction

·         Microsoft.Windows.WaaSMedic.SummaryEvent

The first event is about data is the Medic Service having to perform a repair to Windows Update (I assume, rather than the agent itself?) and the latter gives a nice lot of data on how well that repair went I presume?

Did this event occur in my 30 days’ worth of data?

Yes.

Well, this is interesting, because the SummaryEvent Event occurred 38 times during the 30 days, but the former event didn’t happen at all. Looking at the raw data, it appears this event happened at least once a day, so presumably every time my device was turned on or restarted. Therefore, I deduce it runs a summary of how the Windows as Service Media Agent is and sends that to Microsoft.

Here's one of the data from this event:

data":{"versionString":"10.0.22000.556","callerApplication":"upfc","isInteractiveMode":false,"waasMedicRunMode":0,"capsuleCount":2,"capsuleFailureCount":0,"pluginsCount":18,"pluginFailureCount":0,"hrEngineResult":0,"hrEngineBlockReason":0,"hrLastSandboxError":0,"initSummary":"{\"ServiceHealthPlugin\":\"0\",\"ScheduledTasksPlugin\":\"0\",\"NoUsoScanPlugin\":\"2375681\",\"BinaryHealthPlugin\":\"2375681\",\"ServicingCleanupPlugin\":\"2375681\",\"NotificationManagerPlugin\":\"2375681\",\"DynamicProtectionPlugin\":\"0\",\"TimeSyncPlugin\":\"0\",\"StackDataResetPlugin\":\"2375681\",\"AutomaticCorruptionRepairPlugin\":\"2375681\",\"ManualCorruptionRepairPlugin\":\"2375681\",\"InPlaceUpgradePlugin\":\"2375681\",\"ReserveRepairPlugin\":\"2375681\",\"ResetRepairPlugin\":\"2375681\",\"AppCleanerPlugin\":\"2375681\",\"QuAssistantPlugin\":\"2392068\",\"EnableUUPScanPlugin\":\"2375681\",\"FeatureUpdatePrioritizePlugin\":\"2375681\"}","detectionSummary":"{\"ServiceHealthPlugin\":\"2392067\",\"ScheduledTasksPlugin\":\"2392066\",\"NoUsoScanPlugin\":\"2367491\",\"BinaryHealthPlugin\":\"2367491\",\"ServicingCleanupPlugin\":\"2367491\",\"NotificationManagerPlugin\":\"2367491\",\"DynamicProtectionPlugin\":\"2392066\",\"TimeSyncPlugin\":\"2392067\",\"StackDataResetPlugin\":\"2367490\",\"AutomaticCorruptionRepairPlugin\":\"2367500\",\"ManualCorruptionRepairPlugin\":\"2367500\",\"InPlaceUpgradePlugin\":\"2367491\",\"ReserveRepairPlugin\":\"2367501\",\"ResetRepairPlugin\":\"2367489\",\"AppCleanerPlugin\":\"2367489\",\"QuAssistantPlugin\":\"2392068\",\"EnableUUPScanPlugin\":\"2367489\",\"FeatureUpdatePrioritizePlugin\":\"2367489\"}","remediationSummary":"{\"ServiceHealthPlugin\":\"2367488\",\"ScheduledTasksPlugin\":\"2375683\",\"NoUsoScanPlugin\":\"2367491\",\"BinaryHealthPlugin\":\"2367491\",\"ServicingCleanupPlugin\":\"2367491\",\"NotificationManagerPlugin\":\"2367491\",\"DynamicProtectionPlugin\":\"2375683\",\"TimeSyncPlugin\":\"2367488\",\"StackDataResetPlugin\":\"2367490\",\"AutomaticCorruptionRepairPlugin\":\"2367500\",\"ManualCorruptionRepairPlugin\":\"2367500\",\"InPlaceUpgradePlugin\":\"2367491\",\"ReserveRepairPlugin\":\"2367501\",\"ResetRepairPlugin\":\"2367489\",\"AppCleanerPlugin\":\"2367489\",\"QuAssistantPlugin\":\"2375681\",\"EnableUUPScanPlugin\":\"2367489\",\"FeatureUpdatePrioritizePlugin\":\"2367489\"}","qualityAssessmentImpact":"Low","featureAssessmentImpact":"None","usingBackupFeatureAssessment":true,"usingBackupQualityAssessment":true,"usingCachedFeatureAssessment":false,"usingCachedQualityAssessment":false,"isManaged":false,"isWUConnected":true,"noMoreActions":false}}

 

 

 

Windows Error Reporting events

There’s just the one event in this group and it’s thankfully as clear to understand as the group name:

·         Microsoft.Windows.WERVertical.OSCrash

Despite being vertically challenged, this event sends data from those collected dump file we all know and love when we get a bug check. It’s also when we all know it’s pointless to have it check for solutions online. The data sent contains the size of the dump file, its ID and other specific parameters about the bug check.

Did this event occur in my 30 days’ worth of data?

No.

Amazingly I didn’t have on bug check in those 30 days.

 

 

Windows Hardware Error Architecture events

I didn’t know much about this architecture as I’m slightly more into historical buildings than hardware these days, but apparently, Windows Hardware Error Architecture (WHEA) is an OS mechanism that was introduced way back with Windows Vista SP1 so it’s been around a long time you could say, much like 90% of the Windows OS.

The three events in this group are:

·         WheaProvider.WheaDriverErrorExternal

·         WheaProvider.WheaDriverExternalLogginLimitReached

·         WheaProvider.WheaErrorRecord

They all send back various IDs and flags amongst other data related to WHEA, except the Logging event which is missing a ‘g’ in its name as it sends just a timestamp for when the log limit is reached. There isn’t any or much difference between the data collected in the other two, except that the former is about an external hardware driver.

Did this event occur in my 30 days’ worth of data?

No.

 

 

Windows Update CSP events

The configuration server provider (CSP) is a new name to me and not one I’m totally educated on, but I can say that this group is all about recording data when a feature or Quality update is rolled back. You’ll remember that we users usually get a period where if we have issues with a big feature update, we can easily roll back, and I’d assume the same for quality updates akin to just uninstalling.

The six events in this group are:

·         Microsoft.Windows.UpdateCsp.ExecuteRollBackFeatureFailed

·         Microsoft.Windows.UpdateCsp.ExecuteRollBackFeatureNotApplicable

·         Microsoft.Windows.UpdateCsp.ExecuteRollBackFeatureStarted

·         Microsoft.Windows.UpdateCsp.ExecuteRollBackQualityFailed

·         Microsoft.Windows.UpdateCsp.ExecuteRollBackQualityNotApplicable

·         Microsoft.Windows.UpdateCsp.ExecuteRollBackQualityStarted

The data sent back in the six above is pretty much identical to each other and concerns if the device has updates paused, its OS version, DISM result code, did it reboot successfully, and a few Windows Update for Business-specific data values. My Scooby sense feels this is therefore the types of events more likely to occur on the business device than on my consumer PC

Did this event occur in my 30 days’ worth of data?

No.

 

 

 

Windows Update Delivery Optimization events

As the title says, this is all about Updates and in particular the downloading of them via the Delivery Optimization Client which is the technology Microsoft introduced in Windows 10 as download technology and peer-to-peer distribution method. Thus, our devices could get their content from other devices on the local network or internet as well as including specific settings you can configure for download and upload limits.

There are 5 events in this group:

·         Microsoft.OSG.DU.DeliveryOptClient.DownloadCanceled

·         Microsoft.OSG.DU.DeliveryOptClient.DownloadCompleted

·         Microsoft.OSG.DU.DeliveryOptClient.DownloadPaused

·         Microsoft.OSG.DU.DeliveryOptClient.DownloadStarted

·        Microsoft.OSG.DU.DeliveryOptClient.FailureCdnCommunication

 

As you can see, these events all cover elements of the client’s processes from starting, pausing, completing, and cancelling, as well as any communications errors. The types of data sent to Microsoft HQ in these events are error codes, bytes received and from where, time taken, what files are being sent, file path and file size.

Did this event occur in my 30 days’ worth of data?

Yes.

Given I have this turned on (not sure if it’s default setting) I naturally did send events back, and a lot, although I note some very similar events occur together (so maybe a little duplication) but the very nature of this service is that it’s streaming bits and optimising so I’d kind of expect a little more events than the number of actual updates I had in those 30 days.

·         1              Microsoft.OSG.DU.DeliveryOptClient.DownloadCanceled

·         322         Microsoft.OSG.DU.DeliveryOptClient.DownloadCompleted

·         15           Microsoft.OSG.DU.DeliveryOptClient.DownloadPaused

·         322         Microsoft.OSG.DU.DeliveryOptClient.DownloadStarted

·         8              Microsoft.OSG.DU.DeliveryOptClient.FailureCdnCommunication

An example of one of the Failure events is shown below:

data":{"experimentId":0,"fileID":"f93b65fad216d2fdc80e6ab1da5386d1317ab95b","errorCode":-2145844845,"httpStatusCode":403,"errorCount":1,"sessionID":"ADD50686-2A86-4E68-AEAF-AE24EE261A47","cdnUrl":"http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/56d5c46f-dd65-4579-b29e-4866dfa29055?P1=1646396158&P2=404&P3=2&P4=Jw%2bhRc8wGAGChX%2bKWn0MQD%2beRFVnFc4tqc8lJ58ES%2faj2rIKof56zymJWXXp7MSmUPureKM0yEvwE2USiRj5sQ%3d%3d","cdnIp":"[13.107.4.50]:80;X-CCC:US;X-CID:7;X-MSEdge-Ref:Ref A: 654D1CC1B7E34FC387D5BB2F481E2ACD Ref B: LON04EDGE0610 Ref C: 2022-03-10T14:38:17Z;","cdnHeaders":"HTTP/1.1 403 Forbidden\r\nDate: Thu, 10 Mar 2022 14:38:16 GMT\r\nContent-Length: 45\r\nX-CID: 7\r\nX-CCC: US\r\nX-MSEdge-Ref: Ref A: 654D1CC1B7E34FC387D5BB2F481E2ACD Ref B: LON04EDGE0610 Ref C: 2022-03-10T14:38:17Z\r\n\r\n","isHeadRequest":false,"requestOffset":8388608,"requestSize":741161,"responseSize":0,"peerType":2}}

Windows Update events

There’s a shed load of events in this group, which one would expect, as updates are what makes the Windows world go round. Much like buses, they come along at least daily it seems and sometimes there’s more than one at a time.

The types of events in this grouping can be divided into the following sub-groups:

·         3 of them are about Data Migration Framework (DMF), presumably user settings data maybe, and capture only a handful of data about timings, stages of migration, start times and Windows Update Agent ID.

·         6 are about the various phases of a Device Update Agent, which the documentation describes as involving a “new device manifest UUP (Unified Update Platform) update scenario, which is used to install a device manifest describing a set of driver packages.”

·         Next 7 are about the Orchestrator, and there’s nothing musical about it. The first of these are very specifically looking at the result of installs for Business Critical Application is the Store, an Edge Update and MACUpdate. Weird that they are in this group. The others factor on the reboots during the update UX and about OOBE.

·         The meat of the events is on the Windows Update client, and there seems to be multiple events for every possible outcome of the process, from Checking for Updates, Commit, Download, Install and Revert stages.

·         The rest get into the real depths of various related Windows Update functionality and processes, which is far too deep for me to comprehend and explain.

·         Here’s the full list:

·         Microsoft.Windows.Update.DataMigrationFramework.DmfMigrationCompleted

·         Microsoft.Windows.Update.DataMigrationFramework.DmfMigrationStarted

·         Microsoft.Windows.Update.DataMigrationFramework.MigratorResult

·         Microsoft.Windows.Update.DeviceUpdateAgent.UpdateAgentAnalysisSummary

·         Microsoft.Windows.Update.DeviceUpdateAgent.UpdateAgentDownloadRequest

·         Microsoft.Windows.Update.DeviceUpdateAgent.UpdateAgentInitialize

·         Microsoft.Windows.Update.DeviceUpdateAgent.UpdateAgentInstall

·         Microsoft.Windows.Update.DeviceUpdateAgent.UpdateAgentModeStart

·         Microsoft.Windows.Update.Orchestrator.Client.BizCriticalStoreAppInstallResult

·         Microsoft.Windows.Update.Orchestrator.Client.EdgeUpdateResult

·         Microsoft.Windows.Update.Orchestrator.Client.MACUpdateInstallResult

·         Microsoft.Windows.Update.Orchestrator.UX.InitiatingReboot

·         Microsoft.Windows.Update.Orchestrator.UX.RebootFailed

·         Microsoft.Windows.Update.Orchestrator.Worker.OobeUpdateApproved

·         Microsoft.Windows.Update.Orchestrator.Worker.UpdateActionCritical

·         Microsoft.Windows.Update.WUClient.CheckForUpdatesCanceled

·         Microsoft.Windows.Update.WUClient.CheckForUpdatesFailed

·         Microsoft.Windows.Update.WUClient.CheckForUpdatesRetry

·         Microsoft.Windows.Update.WUClient.CheckForUpdatesScanInitFailed

·         Microsoft.Windows.Update.WUClient.CheckForUpdatesServiceRegistrationFailed

·         Microsoft.Windows.Update.WUClient.CheckForUpdatesStarted

·         Microsoft.Windows.Update.WUClient.CheckForUpdatesSucceeded

·         Microsoft.Windows.Update.WUClient.CommitFailed

·         Microsoft.Windows.Update.WUClient.CommitStarted

·         Microsoft.Windows.Update.WUClient.CommitSucceeded

·         Microsoft.Windows.Update.WUClient.DownloadCanceled

·         Microsoft.Windows.Update.WUClient.DownloadFailed

·         Microsoft.Windows.Update.WUClient.DownloadQueued

·         Microsoft.Windows.Update.WUClient.DownloadStarted

·         Microsoft.Windows.Update.WUClient.DownloadSucceeded

·         Microsoft.Windows.Update.WUClient.DownloadSwitchingToBITS

·         Microsoft.Windows.Update.WUClient.InstallCanceled

·         Microsoft.Windows.Update.WUClient.InstallFailed

·         Microsoft.Windows.Update.WUClient.InstallRebootPending

·         Microsoft.Windows.Update.WUClient.InstallStarted

·         Microsoft.Windows.Update.WUClient.InstallSucceeded

·         Microsoft.Windows.Update.WUClient.RevertFailed

·         Microsoft.Windows.Update.WUClient.RevertStarted

·         Microsoft.Windows.Update.WUClient.RevertSucceeded

·         Microsoft.Windows.Update.WUClient.UpdateDetected

·         Microsoft.Windows.Update.WUClientExt.DataStoreHealth

·         Microsoft.Windows.Update.WUClientExt.DownloadCheckpoint

·         Microsoft.Windows.Update.WUClientExt.DownloadHeartbeat

·         Microsoft.Windows.Update.WUClientExt.UpdateMetadataIntegrity

·        Microsoft.Windows.Update.WUClientExt.UpdateMetadataIntegrityFragmentSigning

·         Microsoft.Windows.Update.WUClientExt.UpdateMetadataIntegritySignature

·         Microsoft.Windows.Update.WUClientExt.UpdateMetadataIntegrityTimestamp

·         Microsoft.Windows.Update.WUClientExt.UUSLoadModuleFailed

·         Microsoft.Windows.WindowsUpdate.RUXIM.ICSEvaluateInteractionCampaign

·         Microsoft.Windows.WindowsUpdate.RUXIM.ICSExit

·         Microsoft.Windows.WindowsUpdate.RUXIM.ICSLaunch

·         Microsoft.Windows.WindowsUpdate.RUXIM.IHEvaluateAndPresent

·         Microsoft.Windows.WindowsUpdate.RUXIM.IHExit

·         Microsoft.Windows.WindowsUpdate.RUXIM.IHLaunch

 

Did this event occur in my 30 days’ worth of data?

No.

Yes, that’s none. Zilch. Don’t ask me why the main group of a ton of events never happened once even though we know Windows Updates happened on my device in these 30 days.

Windows Update mitigation events

The first 3 shown below in this grouping refer to collecting events during an in-place upgrade and reference collecting “Windows Internal Library context used for Product and Service diagnostics” results. The latter three all seem to be rather specific reporting on tidying up any issues during any windows update.

·         Microsoft.Windows.Mitigations.AllowInPlaceUpgrade.ActivityError

·         Microsoft.Windows.Mitigations.AllowInPlaceUpgrade.ApplyTroubleshooting

·        Microsoft.Windows.Mitigations.AllowInPlaceUpgrade.ApplyTroubleshootingComplete

·         Mitigation360Telemetry.MitigationCustom.CleanupSafeOsImages

·         Mitigation360Telemetry.MitigationCustom.FixAppXReparsePoints

·         Mitigation360Telemetry.MitigationCustom.FixupWimmountSysPath

 

Did this event occur in my 30 days’ worth of data?

Yes.

Wasn’t expecting this but I capture 4 of these events in those 30 days:

2	Mitigation360Telemetry.MitigationCustom.CleanupSafeOsImages
2	Mitigation360Telemetry.MitigationCustom.FixupWimmountSysPath

 

Honestly, I can’t really explain the data in any significant way, so I’ll just show you the day from each of the above.

data":{"Result":0,"MitigationScenario":3,"ScenarioSupported":true,"MountedImageCount":0,"MountedImageMatches":0,"MountedImagesFailed":0,"MountedImagesRemoved":0,"MountedImagesSkipped":0,"InstanceId":"AA1AD5FC-E6C2-4E18-82A7-495FD8BA7409","SessionId":"2ddb2c35-de47-447d-9526-9a3cf5ce7cf8","ScenarioId":3,"FlightId":"RS:EBA9","UpdateId":"B63234EC-10E8-4CB9-97DB-F9BBA49CEEF0.1"}}

data":{"Result":0,"MitigationScenario":3,"ScenarioSupported":true,"ImagePathDefault":true,"ImagePathFixedup":false,"InstanceId":"C8041B82-4EF9-4946-8378-E6EBA7A83994","SessionId":"061fd3a9-0816-4a7e-906f-61fc0428d365","ScenarioId":3,"FlightId":"RS:E1A5","UpdateId":"E852C215-2666-4F07-A443-AD93FE142E19.1"}}

 

 

 

Windows Update Reserve Manager events 

I’m assuming this is something to do with portions of the Windows OS being reserved for certain operations, and this is the bit where Windows Update technology meets that aspect. There’s a lack of further explanation in the documentation other than limited details about 12 events in this group which only rewrites the titles of the events:

·         Microsoft.Windows.UpdateReserveManager.BeginScenario

·         Microsoft.Windows.UpdateReserveManager.ClearReserve

·        Microsoft.Windows.UpdateReserveManager.CommitPendingHardReserveAdjustment

·         Microsoft.Windows.UpdateReserveManager.EndScenario

·         Microsoft.Windows.UpdateReserveManager.FunctionReturnedError

·         Microsoft.Windows.UpdateReserveManager.InitializeReserves

·         Microsoft.Windows.UpdateReserveManager.InitializeUpdateReserveManager

·         Microsoft.Windows.UpdateReserveManager.PrepareTIForReserveInitialization

·         Microsoft.Windows.UpdateReserveManager.ReevaluatePolicy

·        Microsoft.Windows.UpdateReserveManager.RemovePendingHardReserveAdjustment

·         Microsoft.Windows.UpdateReserveManager.TurnOffReserves

·         Microsoft.Windows.UpdateReserveManager.UpdatePendingHardReserveAdjustment

Most of the events don’t have many data fields, except InitializeReserves which has around 20+ and records details on free user space scratch reserve space, hard reserve sizes and soft reserve sizes.

Did this event occur in my 30 days’ worth of data?

Yes.

As you can see below from the number of events that occurred, 10 of the events listed above happened which leaves TurnOffReserves and RemovePendingHardReserveAdjustment as the only two that didn’t. Most didn’t really occur much at all except the InitializeUpdateReserveManager which occurred a good handful of times every day during those 30 days, and lots more on days when Windows Updates were being installed (especially after Patch Tuesday). Given its initialising an important functionality, it’s hardly surprising that this event is reported a lot, although like some other events we’ve seen, quite why it’s a ridiculous number of times with a space of seconds I don’t know.

4	Microsoft.Windows.UpdateReserveManager.BeginScenario
4	Microsoft.Windows.UpdateReserveManager.ClearReserve
1	Microsoft.Windows.UpdateReserveManager.CommitPendingHardReserveAdjustment
2	Microsoft.Windows.UpdateReserveManager.EndScenario
3	Microsoft.Windows.UpdateReserveManager.FunctionReturnedError
22	Microsoft.Windows.UpdateReserveManager.InitializeReserves
207	Microsoft.Windows.UpdateReserveManager.InitializeUpdateReserveManager
1	Microsoft.Windows.UpdateReserveManager.PrepareTIForReserveInitialization
2	Microsoft.Windows.UpdateReserveManager.ReevaluatePolicy
2	Microsoft.Windows.UpdateReserveManager.UpdatePendingHardReserveAdjustment

 

Example InitializeReserves event:

data":{"Flags":3,"FallbackInitUsed":0,"HardReserveTargetSize":6272761856,"HardReserveInitialSize":5579862016,"HardReserveFinalSize":5579862016,"HardReserveInitialUsedSpace":0,"HardReserveFinalUsedSpace":0,"SoftReserveTargetSize":1610612736,"SoftReserveInitialSize":1610612736,"SoftReserveFinalSize":1610612736,"SoftReserveInitialUsedSpace":2399617024,"SoftReserveFinalUsedSpace":2399617024,"UpdateScratchReserveInitialSize":0,"UpdateScratchReserveFinalSize":0,"UpdateScratchInitialUsedSpace":0,"UpdateScratchFinalUsedSpace":0,"InitialUserFreeSpace":13569413120,"FinalUserFreeSpace":13569413120,"TargetUserFreeSpace":0,"PostUpgradeFreeSpace":104857600,"FreeSpaceToLeaveInUpdateScratch":0}}

Other Events

After all those events, you’d think that was a job done for me. Bizarrely enough, whilst going through all my data in Excel and cross-referencing with the documentation, I noticed some events were not documented. In some ways I’m surprised, and in others, I’m not. It took a long time to get any telemetry (sorry, diagnostic data) information from Microsoft when Windows 10 came out, so it’s not a big surprise they may be lacking slightly even though they have made a much better effort these days. It’s also possible that the below events are simply that the Diagnostics Data Viewer also picks up other data from any app etc on your device.

Microsoft.Gaming.Critical.ProviderRegistered

First up is the above event which occurred 8 times during the 30 days on the following dates:

08/03/2022 15:00             Microsoft.Gaming.Critical.ProviderRegistered

03/03/2022 14:27             Microsoft.Gaming.Critical.ProviderRegistered

26/02/2022 15:10             Microsoft.Gaming.Critical.ProviderRegistered

21/02/2022 14:20             Microsoft.Gaming.Critical.ProviderRegistered

20/02/2022 15:14             Microsoft.Gaming.Critical.ProviderRegistered

16/02/2022 14:28             Microsoft.Gaming.Critical.ProviderRegistered

12/02/2022 15:09             Microsoft.Gaming.Critical.ProviderRegistered

12/02/2022 14:04             Microsoft.Gaming.Critical.ProviderRegistered

I don’t do any Gaming on my device, but I note that the data in each of the events (see below) does say about the Game Bar, presumably the Xbox Game Bar app that’s on our devices. I don’t use this either but it’s not beyond the possibility it got an update during those 30 days although I’d be surprised if it got updated 8 times.

{"ver":"4.0","name":"Microsoft.Gaming.Critical.ProviderRegistered","time":"2022-03-08T15:00:07.3111710Z","iKey":"o:0a89d516ae714e01ae89c96d185e9ae3","ext":{"utc":{"shellId":281569466025705472,"eventFlags":258,"pgName":"WINCORE","flags":369099365,"epoch":"8005938","seq":1919},"metadata":{"privTags":16777216}," "app":{"id":"U:Microsoft.XboxGamingOverlay_5.721.12013.0_x64__8wekyb3d8bbwe!App","ver":"5.721.12013.0_x64_!2021/12/01:22:26:35!0!gamebar.exe","asId":21692},data":{"providerNamespace":"Microsoft.Gaming.GameOverlay"}}

Windows Store Events

The only other event group I recorded that was not in the documentation related to the following ten events that provide telemetry (sorry, diagnostic data) about the Windows Store. This isn’t documented in the Windows 11 documentation, but I googled it, and it was documented in Windows 10 as “basic” diagnostic data, the old title for required diagnostic data. You can read the details here https://docs.microsoft.com/en-gb/windows/privacy/basic-level-windows-diagnostic-events-and-fields-1803#windows-store-events I suspect someone just forgot to copy/paste it into the Windows 11 documentation?

Microsoft love their app store and they continue to evolve it over the years (or flog it to death you could say) as they attempt to get us using it more and more. Naturally they want to know how people use the app and how well it performs so there’s all these events:

 

·         Microsoft.Windows.Store.StoreActivating

·         Microsoft.Windows.StoreAgent.Telemetry.AbortedInstallation

·         Microsoft.Windows.StoreAgent.Telemetry.BeginGetInstalledContentIds

·         Microsoft.Windows.StoreAgent.Telemetry.BeginUpdateMetadataPrepare

·         Microsoft.Windows.StoreAgent.Telemetry.CancelInstallation

·         Microsoft.Windows.StoreAgent.Telemetry.CompleteInstallOperationRequest

·         Microsoft.Windows.StoreAgent.Telemetry.EndAcquireLicense

·         Microsoft.Windows.StoreAgent.Telemetry.EndDownload

·         Microsoft.Windows.StoreAgent.Telemetry.EndFrameworkUpdate

·         Microsoft.Windows.StoreAgent.Telemetry.EndGetInstalledContentIds

·         Microsoft.Windows.StoreAgent.Telemetry.EndInstall

·         Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates

·         Microsoft.Windows.StoreAgent.Telemetry.EndSearchUpdatePackages

·         Microsoft.Windows.StoreAgent.Telemetry.EndStageUserData

·         Microsoft.Windows.StoreAgent.Telemetry.EndUpdateMetadataPrepare

·         Microsoft.Windows.StoreAgent.Telemetry.FulfillmentComplete

·         Microsoft.Windows.StoreAgent.Telemetry.FulfillmentInitiate

·         Microsoft.Windows.StoreAgent.Telemetry.InstallOperationRequest

·         Microsoft.Windows.StoreAgent.Telemetry.PauseInstallation

·         Microsoft.Windows.StoreAgent.Telemetry.ResumeInstallation

·         Microsoft.Windows.StoreAgent.Telemetry.ResumeOperationRequest

·        Microsoft.Windows.StoreAgent.Telemetry.SearchForUpdateOperationRequest

·         Microsoft.Windows.StoreAgent.Telemetry.UpdateAppOperationRequest

 A lot of these are obvious and relate directly to the installation or update of an app in the store. StoreActivating relates to “Store app activation via protocol URI in progress” and I’m guessing this only happens once or maybe when there’s a store update? There are only 3 data values in this event. The documentation says nothing about BeginGetInstalledContentIds data contents except that it’s sent when an inventory of apps installed is started to determine if updates are available which seems obvious enough but as you’ll see I never got this event despite checking for apps every day. Likewise, BeginUpdateMetadataPrepare is about when the Store Cache is refreshed with an app update but has no information in the old documentation and never happened in the 30 days of data. It could be that these events were discontinued from Windows 10 to 11. The two Fulfilment events are very simply the installation events as they report on which app is being installed and its success or error code. All in all, a lot of these events don’t report back more than a handful of data except those related to installation or downloads.

Did this event occur in my 30 days’ worth of data?

Yes.

I’m quite trigger happy on checking for updates in the store or windows even though I have auto-update turned off in the store. At least once a day I just can’t help checking for updates so my number of events might well be more than most, or they might be less as I have uninstalled a lot of the Microsoft crapware apps that you get by default in windows.

As you can see below the EndScanForUpdates occurs a lot although looking at the data, it seems to happen at least 2-3 times in quick succession, so I suspect a few duplicates in there? Certainly, EndAcquireLicense I’ve seen evidence of it running with near enough the same data values twice in a matter of seconds:

50	Microsoft.Windows.StoreAgent.Telemetry.EndAcquireLicense
25	Microsoft.Windows.StoreAgent.Telemetry.EndDownload
25	Microsoft.Windows.StoreAgent.Telemetry.EndInstall
133	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates
25	Microsoft.Windows.StoreAgent.Telemetry.FulfillmentComplete
25	Microsoft.Windows.StoreAgent.Telemetry.FulfillmentInitiate
5	Microsoft.Windows.StoreAgent.Telemetry.ResumeInstallation
5	Microsoft.Windows.StoreAgent.Telemetry.ResumeOperationRequest
1	Microsoft.Windows.StoreAgent.Telemetry.SearchForUpdateOperationRequest
60	Microsoft.Windows.StoreAgent.Telemetry.StateTransition

 

You can see below the typical chronological order of the store events, with the EndScanForUpdates seemingly running a heck of a lot more often than needed:

12/02/2022 14:09	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates
12/02/2022 14:11	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates
12/02/2022 14:21	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates
12/02/2022 14:23	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates
12/02/2022 14:23	Microsoft.Windows.StoreAgent.Telemetry.EndAcquireLicense
12/02/2022 14:23	Microsoft.Windows.StoreAgent.Telemetry.EndAcquireLicense
12/02/2022 14:23	Microsoft.Windows.StoreAgent.Telemetry.FulfillmentInitiate
12/02/2022 14:23	Microsoft.Windows.StoreAgent.Telemetry.StateTransition
12/02/2022 14:24	Microsoft.Windows.StoreAgent.Telemetry.EndDownload
12/02/2022 14:24	Microsoft.Windows.StoreAgent.Telemetry.EndInstall
12/02/2022 14:24	Microsoft.Windows.StoreAgent.Telemetry.FulfillmentComplete
12/02/2022 14:24	Microsoft.Windows.StoreAgent.Telemetry.StateTransition
12/02/2022 14:41	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates
12/02/2022 14:41	Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates

Microsoft.Windows.StoreAgent.Telemetry.EndScanForUpdates

 

"data": {

"IsOnline": 2,

"IsApplicability": 0,

"IsInteractive": 16,

"ClientAppId": "Update;",

"HResult": 0

}

Microsoft.Windows.StoreAgent.Telemetry.StateTransition

"data": {

"ProductId": "9WZDNCRF0083",

"PFN": "Facebook.317180B0BB486_8xx8rvfyw5nnt",

"CatalogId": "",

"FulfillmentPluginId": "WU",

"PluginTelemetryData": "{\"OperationType\":\"Update\",\"ClientAppId\":\"Update;Microsoft.WindowsStore_8wekyb3d8bbwe\",\"ContentId\":\"FACEBOOK.317180B0BB486_1530.17.110.0_x64__8xx8rvfyw5nnt\",\"WUContentId\":\"fc13f4b7-b219-5967-e7e3-912b4e4663b2\",\"IsRemediation\":0,\"CategoryId\":\"c6a9fa5c-20a2-4e12-904d-edd408657dc8\",\"ParentBundleId\":\"\",\"DownloadSize\":39913386,\"SystemAttemptNumber\":0,\"UserAttemptNumber\":1,\"AttemptNumber\":1,\"WorkProperties\":{\"IsInteractive\":1,\"CallerApplicationId\":\"Microsoft.WindowsStore_8wekyb3d8bbwe\",\"InstallForAllUsers\":0,\"AllowDownloadOnAnyNetwork\":0,\"ForceUseOfNonRemovableStorage\":0,\"AllowForcedAppRestart\":1,\"IsDiscInstall\":0,\"IsRestore\":0,\"Repair\":0,\"StageButDoNotInstall\":0,\"RequiresElevation\":0,\"AutomaticallyDownloadAndInstallUpdateIfFound\":1,\"AllowCachedResult\":0,\"UserIdentityInfo\":\"\",\"VolumePath\":\"\"},\"extendedErrorCode\":0}",

"Prevstate": "Working",

"NewState": "Completed",

"PluginLastStage": 5,

"HResult": 0

}