Windows 10 Settings crashes when verifying Microsoft account in Windows Backup

Question

Windows 10 Settings crashes when verifying Microsoft account in Windows Backup

Andrei Damian 0

I'm having a problem with Settings on Windows 10 Pro 22H2 (build 19045.7725).

When I open Windows Backup and click Backup, it says OneDrive is needed to back up my files, then asks me to verify my Microsoft account to back up credentials. If I click Go to settings, Settings opens and immediately crashes, and the button changes to Retry. The Windows Update page also loads suspiciously slow, never had it do that before and the whole Settings app runs poorly

I'm already signed in to my Microsoft account, and there's no Verify button under Settings → Accounts → Your info. The other Accounts pages and Windows Update also take a very long time to load.

Event Viewer reports:

Faulting application: SystemSettings.exe (10.0.19041.7725)

Faulting module: Windows.UI.Xaml.dll (10.0.19041.7725)

Exception code: 0xc000027b

Fault offset: 0x00000000007239b0

Package: windows.immersivecontrolpanel_10.0.2.1000_neutral_neutral_cw5n1h2txyewy

Report ID: [PII removed]

I also have an earlier Reliability Monitor crash report showing KERNELBASE.dll with exception 0xe06d7363.

I performed an in-place repair using the Windows Media Creation Tool, preserving my files and apps. Settings worked normally afterward, but the problem returned after I changed some services and applied privacy tweaks using Chris Titus Tech WinUtil. These included removing OneDrive and Edge, Windows AI and Widgets tweaks, and service and telemetry changes. I can't confirm which change, if any, caused it.

I've tried re-registering Microsoft.AccountsControl and Microsoft.AAD.BrokerPlugin, but neither fixed the crash. I also checked the relevant account services, and they were running.

Has anyone encountered this on Windows 10? Is this a known issue with Windows Backup or Settings, and is there a way to identify the underlying exception without reinstalling Windows again?

0 comments

1 answer

Your answer

Answer 1

Kai-H 28,525 Microsoft External Staff Moderator

(Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.)

Hi, Andrei Damian

The repair working until the tweaks were applied makes those changes worth investigating, but it doesn’t prove which one caused this. 0xc000027b is a “stowed exception,” so the Event Viewer entry alone doesn’t reveal the underlying error.

Here are some suggestions you can try:

In WinUtil’s Tweaks tab, select the changes you previously applied and choose Undo Selected Tweaks, then restart and retest. I’d start with the service and privacy changes rather than repeat the account-package registrations.

To investigate before changing anything, download ProcDump, extract it, and open Command Prompt as administrator in that folder. Create C:\Dumps, then run:

procdump.exe -ma -e -w SystemSettings.exe C:\Dumps

Reproduce the crash to capture a full dump. Keep it private because it contains process memory.

For deeper analysis, the dump can be examined in WinDbg using .exr -1 and !pde.dse. The latter requires the PDE extension and can expose the original error and call stack.

Andrei Damian 0 Reputation points

2026-10-12T14:01:42.2266667+00:00

Hi Kai-H,

Thanks for your help. I managed to capture the dump with ProcDump and open it in WinDbg, but I'm stuck trying to run !pde.dse.

WinDbg says it can't find the PDE extension when I run .load pde. I tried the OneDrive link from the debugging documentation, but it doesn't work for me, it says I don't have permission

The dump shows a wil::ResultException (0xe06d7363), and the stack trace points to SyncSettings::DataModel::SyncSettingsSingleton::UpdateDeviceTrustState. The original crash in Event Viewer was 0xc000027b, with Windows.UI.Xaml.dll as the faulting module.

I'm using Windows 10 Pro 22H2 (build 19045.7727), WinDbg 1.2610.1001.0, and ProcDump 12.01.

Could you point me to a working download for PDE or suggest another way to inspect the original stowed exception? I'd prefer to identify the cause before making any more changes to my Windows configuration.

Thanks again!
Kai-H 28,525 Reputation points Microsoft External Staff Moderator

2026-10-13T08:52:17.46+00:00

Hi, Andrei Damian

Thanks for capturing that. UpdateDeviceTrustState is a useful lead, but it doesn’t identify the cause by itself, and there hasn't been a working replacement PDE download.

You can investigate without PDE. First, run these commands in WinDbg:

.symfix

.reload

!analyze -v

.exr -1

.ecxr

k

These show the exception record and its associated stack.

Check what .exr -1 actually reports. If it shows 0xe06d7363, don’t interpret its parameters as stowed-exception pointers. For 0xc000027b, Parameter[0] is the pointer-array address and Parameter[1] is the count.

For a dump containing 0xc000027b, !analyze -v may provide a STACK_COMMAND with dt ... combase!STOWED_EXCEPTION_INFORMATION_V2 -r and dps ... commands. Use the addresses from your output. The structure’s ResultCode contains the underlying HRESULT.

If your dump only contains the C++ exception, capture again using -ma -e, without the 1 after -e, which enables first-chance capture.

Please paste the .exr -1 output and !analyze -v exception section, with personal paths removed, rather than posting the full dump.
Andrei Damian 0 Reputation points

2026-10-13T12:23:58.1533333+00:00

I continued debugging live in WinDbg and found a more specific error path

The trace repeatedly reports 0x80040154 (“Class not registered”) in Windows.CloudStore.dll, at cdpobjectfactory.cpp line 124. The error propagates through cloudstorepolicy.cpp (lines 124 and 151) and SyncSettings.dll!UpdateDeviceTrustState. I confirmed EAX=80040154 immediately after the failing call. The relevant Cloud Store policy vtable entry resolves to CloudStorePolicy::GetAuthenticationPolicy. Settings also logs the error for SystemSettings_SyncSettings_TrustPCStatusLink and SystemSettings_SyncSettings_PageStatusLink.

Can we identify which class the Cloud Store object factory is failing to activate, or determine what registration I should investigate next?
Kai-H 28,525 Reputation points Microsoft External Staff Moderator

2026-10-14T08:49:33.26+00:00

Hi, Andrei Damian

That narrows the failure considerably. 0x80040154 from cdpobjectfactory.cpp indicates that CloudStore attempted to activate a COM or WinRT class that is no longer registered or available. However, that error alone does not identify the missing class. I would not manually register Windows.CloudStore.dll with regsvr32, because it is a Windows component and may not use traditional self-registration.

Given that the problem appeared after service and privacy changes, first verify that the Connected Devices Platform components were not disabled:

sc query CDPSvc

sc qc CDPSvc

sc query TokenBroker

sc qc TokenBroker

Also open services.msc and check for Connected Devices Platform Service and the per-user Connected Devices Platform User Service. If WinUtil disabled either service, restore the relevant tweak rather than forcing an arbitrary startup value manually.

To identify the missing registration more precisely, use Process Monitor:

Start Process Monitor as administrator.

Filter Process Name is SystemSettings.exe.

Add filters for Result is NAME NOT FOUND and Result is PATH NOT FOUND.

Reproduce the Settings crash.

Inspect the final registry failures under paths containing Classes, CLSID, or ActivatableClasses.

A missing path immediately before the Windows.CloudStore.dll failure may reveal the class name or CLSID that CloudStore is trying to activate.

It would also be useful to test the same Windows Backup page from a newly created local Windows user profile. If the page works there, the registration is probably intact and the damage is more likely confined to the original profile’s CloudStore data or per-user service configuration. If the crash occurs in the new profile as well, that points more strongly to a system-wide service or registration change.

Please share the last few relevant Process Monitor registry failures with usernames and personal paths removed. Do not post the full capture, because it may contain private information.