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:
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:
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:
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:
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:
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:
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:
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:
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:
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.
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
}