Fix 0x000036C6: SXS Duplicate Window Class Name Error

This error is a pain.

You're trying to launch an app — maybe a legacy line-of-business tool, some old .NET app, or a custom shell extension — and instead you get 0x000036C6 (ERROR_SXS_DUPLICATE_WINDOWCLASS_NAME). The app closes instantly. You've checked Event Viewer and seen the same SXS error under Application logs. Let's fix it.

The real fix: Rebuild the SXS cache

The culprit here is almost always a corrupted or mismatched side-by-side assembly cache (WinSxS). Two DLLs registered the same window class name, usually ComCtl32 or UxTheme related. Don't bother with reinstalling the app — that rarely helps because the problem is system-wide.

Open an elevated Command Prompt — right-click Start, choose Terminal (Admin) or Command Prompt (Admin).
Run DISM to restore health:
```
DISM /Online /Cleanup-Image /RestoreHealth
```
This downloads fresh copies of corrupted system files. Let it finish — could take 10-20 minutes.
Then run SFC:
```
sfc /scannow
```
This checks and replaces any system files that DISM found corrupt.
Reboot. Yes, you have to.
Re-register the SXS assemblies:
```
regsvr32 /s %windir%\system32\comctl32.dll
regsvr32 /s %windir%\system32\uxtheme.dll
```
Use /s (silent) to avoid popups. If you get access denied, you're not running as admin.
Clear the SXS cache (safe version):
```
dism /online /cleanup-image /startcomponentcleanup
```
This removes superseded versions of assemblies. Takes a minute.

After that, try launching the app again. 9 times out of 10, it works.

Why this works

The SXS cache holds multiple versions of the same DLL. Windows uses manifests to tell an app which version to load. If two manifests point to different DLLs that both register a window class named SysListView32 or ToolbarWindow32, the system throws 0x000036C6. DISM and SFC restore those manifests to their original state. The startcomponentcleanup prunes old versions that shouldn't be there anymore. Re-registering the key DLLs forces the class names to be re-registered cleanly.

I've seen this happen most often after a Windows Update that partially failed — the update drops a new version of ComCtl32 but doesn't clean up the old one. The next app that tries to load both versions chokes on the duplicate class name.

Less common variations of the same issue

Sometimes the error isn't from system DLLs. It could be from third-party shell extensions or accessibility tools that inject hooks.

Third-party shell extensions: Tools like Dropbox Explorer extensions, NVIDIA shell extensions, or older antivirus components can register window classes that conflict. Use Autoruns (from Sysinternals) to disable non-Microsoft shell extensions one by one. Reboot after each change until the error stops.
Accessibility software: Screen readers (JAWS, NVDA) and magnifiers sometimes register multiple instances of the same class. Disable the service, test, then re-enable with a clean install.
Corrupted user profile: If the error only happens for one user, their profile has a bad registry key under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer. Create a new profile and copy data over.
Manually installed .NET or C++ runtimes: Installing multiple side-by-side versions of the same runtime (e.g., VC++ 2015 and 2017 redistributables) can cause this. Uninstall all redistributables, then install the latest all-in-one version from Microsoft's site.

How to prevent this from happening again

You can't fully prevent Windows Update hiccups, but you can reduce the chances.

Keep Windows up to date. Sounds obvious, but cumulative updates fix SXS corruption bugs. Install them monthly.
Use DISM regularly. Run DISM /Online /Cleanup-Image /AnalyzeComponentStore every few months. If it shows a high number of superseded components, run startcomponentcleanup to keep the cache lean.
Avoid installing beta or preview builds on production machines. They leave orphaned assemblies that trigger this exact error.
Uninstall old software cleanly. Don't just delete folders — use the uninstaller. Orphaned DLLs in SysWOW64 or System32 can register window classes that conflict years later.

If you ever see 0x000036C6 again, you now know the drill: DISM, SFC, re-register, reboot. Skip the app reinstall dance — it's a waste of time.