Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Windows System Log · Event 10010
Windows asked a background component to start, waited its fixed timeout, and gave up. The component usually starts a moment later anyway, which is why this error rarely matches any symptom you can see. The only field worth reading is the CLSID, and it is the one nobody explains.
Also written as Event ID 10010DistributedCOM 10010DCOM timeout CLSID
This looks alarming and is almost never anything. It usually means a piece of Windows or a Store app was slow off the mark while your PC was still booting or waking up, and Windows lost patience. If your machine works normally, you can ignore it. A burst of them right after an update is particularly common.
Worth a look only when it is repetitive and tied to a service that genuinely matters — WMI providers, backup agents, and monitoring tools that host out-of-process COM servers. Resolve the CLSID before spending any time on it; on client SKUs the answer is very often a per-user COM server from a Store package that was updated or removed.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
Log Name: System
Source: Microsoft-Windows-DistributedCOM
Event ID: 10010
Level: Error
Computer: DESKTOP-WKS042
The server {00000000-0000-0000-0000-000000000000} did not register with DCOM within the required timeout.Everything else in the log line is context.
Most of the time it is one of these.
What gives it awayResolve the CLSID: if LocalServer32 or InprocServer32 points at a path in a user profile, a temp directory, or a name that does not match the component, that is the finding rather than the timeout.
ATT&CK T1546.015What gives it away10010 on the target with an unfamiliar remote-activation pattern, alongside Security 4624 Logon Type 3 from an unexpected source around the same time.
ATT&CK T1021.003Get-WinEvent -FilterHashtable @{LogName='System'; Id=10010} -MaxEvents 50 | Select-Object TimeCreated, @{n='CLSID';e={$_.Properties[0].Value}} | Group-Object CLSID | Sort-Object Count -Descending$g='{00000000-0000-0000-0000-000000000000}'; Get-ItemProperty "Registry::HKEY_CLASSES_ROOT\CLSID\$g" ; Get-ItemProperty "Registry::HKEY_CLASSES_ROOT\CLSID\$g\LocalServer32"Event | where EventID == 10010 | extend CLSID = extract(@'\{([0-9A-Fa-f-]{36})\}', 1, RenderedDescription) | summarize count() by Computer, CLSID | order by count_ descAlmost never on a normal PC. It means a background component did not report in before Windows' timeout expired, and in most cases it started successfully immediately afterwards. If your machine boots, runs, and shuts down normally, this event is not describing a problem you have.
The event gives you a CLSID in braces. Open Registry Editor, go to HKEY_CLASSES_ROOT\CLSID and find that GUID — the key's default value is normally a readable component name, and the LocalServer32 subkey shows the executable behind it. If the GUID is not there at all, the registration is left over from software that has been removed.
10016 is a permission problem: an account was denied Local Activation or Local Launch on a COM component, and on Windows 10 and 11 it is a known, harmless side effect of how Microsoft locked down its own components. 10010 is a timing problem: the component was allowed to start but did not report back fast enough. Different causes, and only 10010 can occasionally indicate something real.
You can, but you almost certainly should not. The timeout is a system-wide value, raising it slows down every legitimate activation failure across the machine, and it hides the symptom rather than fixing anything. If a specific component keeps timing out, repair or reinstall that component instead.
Last reviewed 7 September 2026