Hi,

Since SFC, DISM and ViVeTool have already been checked, I would try these next:

Check if any third-party Explorer tools like ExplorerPatcher, StartAllBack or Windhawk are installed. Disable/uninstall them temporarily and restart Explorer.

Create a new local Windows user and check whether File Explorer shows tabs there.

If the issue is still there, perform a clean boot to rule out any third-party service or startup application.

I would avoid forcing the removal of KB5124010 because 0x800f0905 indicates a servicing/package issue.

If the problem occurs even with a new user and clean boot, it looks more like a system-level Explorer issue, and an in-place Windows repair would be the next step.

Thanks

Do you have this showing in Windows 11 File Explorer?

If it's not there then look at this article. This is an answer that is already provided, and should help answer this topics question!

https://dellenny.com/how-to-enable-tabs-in-file-explorer-in-windows-11/

Windows 11 File Explorer Modern Components Not Activating — Diagnostic Report

Summary

I am investigating a Windows 11 File Explorer issue where the modern File Explorer components appear to be installed and registered, but the corresponding modern File Explorer assemblies do not appear to be activated or loaded when Explorer functionality is used.

The investigation has so far ruled out several possible explanations, including a simple missing-DLL problem, an obviously broken MicrosoftWindows.Client.FileExp AppX package, a conventional Explorer binary/version mismatch, and Windhawk interference.

The main unresolved question is whether Windows is not selecting/activating the modern File Explorer components at all, or whether activation is occurring through a mechanism that is not visible through the normal process/module and event-log checks.

Importantly, the problem was already present before the later update I previously referred to as “4010.” I am therefore not attributing the original problem to that update.

System Information

Device: ASUS ROG Strix G16 (2023)

Model: G614JV

CPU: Intel Core i7-13650HX

GPU: NVIDIA RTX 4060

RAM: 16 GB

Operating system reported by Windows: Windows 10 Pro / Version 2009

Current OS build: 26300

DISM image version: 10.0.26300.9539

Current servicing packages include:

26100.9539 servicing stack

  26100.9550 cumulative update

  
     related components around 26100.9549
```There appears to be a mixture of OS/build and component/package version numbering, but the investigation established that this is **not evidence of an Explorer binary mismatch**.

---
# 1. Explorer executable was investigated

The active Explorer executable is:

`C:\Windows\explorer.exe`

Its reported file/product version is:

`10.0.26100.8117`

The file was compared directly against the corresponding Explorer binary in WinSxS:

`C:\Windows\WinSxS\amd64_microsoft-windows-explorer_31bf3856ad364e35_10.0.26100.9549_none_ed6ef9b729c87d90\explorer.exe`

Both files have the exact same SHA-256 hash:

`34AC55B23B6D840CC9FA8304C0149B8BB026D817B39610728092878D634A61EB`

Therefore, the apparent difference between the `26100.8117` file version and the `26100.9549` WinSxS directory name does **not** represent two different Explorer binaries.

This ruled out the earlier hypothesis that Windows was simply running an older Explorer binary while a newer Explorer binary was sitting unused in WinSxS.

---
# 2. MicrosoftWindows.Client.FileExp package is installed

The Microsoft File Explorer AppX package is present:

**Package:** MicrosoftWindows.Client.FileExp

**Package version:** 1000.26100.10.0

**Status:** OK

**Install location:**

`C:\Windows\SystemApps\MicrosoftWindows.Client.FileExp_cw5n1h2txyewy`

The package is therefore not simply missing or uninstalled.

---
# 3. Modern File Explorer DLLs physically exist

The package contains the expected modern File Explorer components.

### FileExplorerExtensions.dll

Location:

`C:\Windows\SystemApps\MicrosoftWindows.Client.FileExp_cw5n1h2txyewy\FileExplorerExtensions.dll`

Reported version:

`2608.25001.0.0`

Size:

approximately 6.4 MB

### FileExplorerManaged.dll

Location:

`C:\Windows\SystemApps\MicrosoftWindows.Client.FileExp_cw5n1h2txyewy\FileExplorerManaged.dll`

Reported version:

`10.0.26100.9549`

Both files physically exist in the expected SystemApps location.

Therefore, this is not currently consistent with a simple missing File Explorer DLL.

---
# 4. The physical FileExp manifest contains modern File Explorer registrations

The physical AppX manifest was inspected directly.

It contains registrations for both:

`FileExplorerManaged`

`FileExplorerExtensions`

The manifest includes modern File Explorer extension registrations such as:

ContextMenu

CommandBarExtension

TabsExtension

DetailsPaneExtension

FolderViewExtension

NavigationContentExtension

It also contains the ShellHost component registration for the File Explorer property-sheet functionality.

Of particular interest, the manifest contains:

`UseWinUI3 = true`

and identifies:

`Microsoft.WindowsAppRuntime.CBS.1.6_8wekyb3d8bbwe`

as the target Windows App SDK package.

The manifest therefore clearly describes a modern WinUI 3 / Windows App SDK-based File Explorer component architecture.

This is important because the physical package is not merely an old or empty compatibility package.

---
# 5. FileExp dependencies are present and healthy

The relevant Microsoft client components were also checked.

The following packages were present with an OK status:

MicrosoftWindows.Client.Core — 1000.26100.134.0

MicrosoftWindows.Client.CBS — 1000.26100.372.0

UI.Xaml.CBS — 9.2603.18001.0

ShellExperienceHost — 10.0.26100.8115

This does not prove that every activation dependency is functioning correctly, but there is no obvious indication that the required Microsoft client packages are simply absent.

---
# 6. Feature ID 49682398 is enabled

The Windows feature associated with the modern File Explorer implementation was checked.

Feature:

**49682398 — FileExplorer_InMarket_24A_Backport**

Current state:

**Enabled**

Priority:

**ImageOverride (15)**

Therefore, the relevant feature is not simply disabled through ViVeTool.

No changes were made to this feature during the investigation.

---
# 7. ShellHost contains modern Shell/XAML infrastructure

ShellHost was inspected directly.

The running process is:

`C:\Windows\System32\ShellHost.exe`

It has the following relevant modules loaded:

`windowsudk.shellcommon.dll`

`Microsoft.UI.Xaml.dll`

The Microsoft UI XAML component is loaded from:

`C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\Microsoft.UI.Xaml.dll`

This demonstrates that ShellHost is not running without the underlying modern XAML/Windows Shell infrastructure.

However, the following File Explorer-specific assemblies were **not** present in ShellHost:

FileExplorerExtensions.dll

FileExplorerManaged.dll

---
# 8. Explorer/ShellHost did not show FileExp DLL activation

Multiple direct module checks were performed for:

`FileExplorerExtensions.dll`

`FileExplorerManaged.dll`

The result repeatedly indicated that no running process had either module loaded.

This was tested after exercising File Explorer functionality, including normal Explorer navigation and UI operations.

The test was repeated rather than relying on a single observation.

The same result was obtained:

FileExplorerExtensions.dll — not loaded

FileExplorerManaged.dll — not loaded

This is one of the more significant findings in the investigation.

It does not by itself prove that the components are broken, because modern Windows AppX/AppExtension components do not necessarily behave like traditional Explorer shell DLLs. However, the absence remained noteworthy even after explicitly exercising Explorer functionality.

---
# 9. Conventional CLSID investigation did not find the components

A search of the conventional HKLM CLSID/InprocServer32 registration area for File Explorer-related DLL registrations did not find the FileExp components.

This was not interpreted as evidence of corruption.

The reason is that the inspected manifest uses modern AppX/AppExtension and ShellHost registrations rather than relying solely on the older Win32 CLSID/InprocServer32 mechanism.

Therefore, this test was useful mainly for establishing that the modern FileExp implementation is not obviously registered through the traditional shell-extension mechanism.

---
# 10. Windhawk was investigated and eliminated as the current confounder

Windhawk was initially present and was therefore considered a possible source of Explorer interference.

A Windhawk modification named:

`explorer-details-better-file-sizes_1.5.1_949730.dll`

was found to be injected into multiple processes, including Explorer and ShellHost.

The mod was disabled.

Windhawk was subsequently disabled/removed from runtime and the system was rebooted.

After that clean-state testing, the File Explorer investigation was repeated.

The FileExp DLLs still did not appear in the running processes.

Therefore, the current findings cannot reasonably be attributed simply to the Windhawk Explorer modification.

I am deliberately not continuing to use Windhawk as the primary explanation.

---
# 11. AppModel-Runtime event log was checked

The following Windows event channel is enabled:

**Microsoft-Windows-AppModel-Runtime/Admin**

Recent events were examined.

The channel is functioning normally and is actively recording AppX activity.

For example, it records creation and destruction of Desktop AppX containers for applications including:

Microsoft Windows Terminal

MicrosoftWindows.Client.CBS

Nearby Share

Microsoft PowerToys components

Windows Notepad

WinRAR shell components

Notepad++

other packaged applications

It also recorded an actual process launch for:

`MicrosoftWindows.Client.CBS_cw5n1h2txyewy!CrossDeviceResumeApp`

This is useful because it demonstrates that AppModel-Runtime logging is operational.

However, during the File Explorer investigation there were no corresponding recent events identifying:

MicrosoftWindows.Client.FileExp

FileExplorerExtensions

FileExplorerManaged

No obvious AppModel activation error related to File Explorer was found in the examined recent events.

---
# 12. Controlled Explorer test did not generate a FileExp AppModel event

A controlled test was performed after establishing the existing AppModel event timestamp.

File Explorer was opened and normal Explorer operations were performed, including:

navigating into a normal folder

opening the Details pane

closing the Details pane

right-clicking a normal file

The AppModel-Runtime/Admin log was then checked immediately afterward.

There was no new FileExp-related event.

The newest AppModel event remained an unrelated Windows Terminal event from earlier.

Therefore, during this test there was no observable AppModel-Runtime activation event for the File Explorer components.

---
# 13. Shell-Core/Operational event log was also investigated

The following channel is enabled:

**Microsoft-Windows-Shell-Core/Operational**

The latest events were examined.

The channel is functioning and records normal Shell activity, including:

AppResolver scans

AppResolver cache commits

application shortcut updates

startup Run/RunOnce processing

execution of startup applications

Examples included Microsoft Edge, Google Chrome, Lightshot, Everything, and Internet Download Manager.

However, the examined recent events did not contain:

FileExplorerExtensions

FileExplorerManaged

MicrosoftWindows.Client.FileExp

an obvious ShellHost/File Explorer activation failure

an Explorer-related error corresponding to the controlled test

Therefore, this log also did not provide evidence of an attempted FileExp activation.

---
# 14. AppX registry-path investigation

The Windows AppX registry area was also checked for a direct `MicrosoftWindows.Client.FileExp` entry under the expected AppX all-user application registration path.

No matching key was returned.

However, this result is **not being treated as proof that the package is incorrectly registered**.

The reason is that modern Windows AppX/AppExtension registration is more complicated than simply checking that one registry path. The package is already demonstrably registered through the Windows AppX package-management layer, and its physical manifest contains the expected modern registrations.

Therefore, no registry modifications were made based on this result.

---
# Current findings

At this stage, the investigation has established the following:

### Confirmed

The MicrosoftWindows.Client.FileExp package exists.

Its AppX status is OK.

The physical File Explorer extension DLLs exist.

The physical manifest contains the expected modern File Explorer extension registrations.

The manifest specifies WinUI 3.

The manifest references the Windows App SDK target.

Required Microsoft client/XAML packages are present.

Feature 49682398 is enabled.

ShellHost is running.

ShellHost has modern Windows UDK/XAML infrastructure loaded.

Explorer and the corresponding WinSxS Explorer file are byte-for-byte identical.

Windhawk has been removed from the current runtime test environment.

Repeated module checks do not show the FileExp DLLs loaded.

Controlled Explorer operations did not generate corresponding FileExp events in AppModel-Runtime/Admin.

Shell-Core/Operational did not show a corresponding FileExp activation/error event in the examined period.

### Not established

The investigation has **not yet established** whether:

Windows is deliberately selecting a different File Explorer implementation;

the FileExp AppExtension registration is not being selected;

ShellHost is attempting activation through another mechanism not visible in these logs;

activation is failing before the DLL is loaded;

the relevant feature/servicing configuration is causing the modern implementation not to be selected;

or there is another problem in the Shell/AppX activation path.

I therefore do not want to label this as an AppX corruption problem without further evidence.

---
# Why I am requesting further investigation

The unusual combination is:

> **The modern File Explorer package and its required components are physically present, the feature is enabled, the manifest contains the expected modern registrations, and the Shell has modern XAML infrastructure, but the FileExp-specific components do not appear to activate during normal Explorer operations.**

The absence of FileExp-related AppModel and Shell-Core events is also notable.

I am looking for a way to determine **where the activation chain stops** rather than immediately re-registering or replacing system components.

In particular, I would like to determine whether Windows is:

not attempting to activate `MicrosoftWindows.Client.FileExp` at all,

attempting activation and failing before module loading,

activating it through another process/mechanism,

or deliberately selecting a different implementation because of feature/servicing state.

---
# Diagnostic actions deliberately NOT performed

I have not:

manually replaced `explorer.exe`;

copied Explorer DLLs from another Windows installation;

modified files inside `SystemApps`;

manually deleted the FileExp package;

manually re-registered the package using potentially destructive commands;

changed the 49682398 feature state;

modified the FileExp manifest;

modified the ShellHost executable;

modified WinSxS files;

assumed the WinSxS directory version represented the internal Explorer executable version;

continued blaming Windhawk after removing it from the test environment.

I would prefer to identify the activation failure/path first before making system-level changes.

---
# Requested assistance

Could someone familiar with the current Windows 11 File Explorer/AppExtension architecture advise on the appropriate diagnostic mechanism for tracing activation of:

`MicrosoftWindows.Client.FileExp`

and specifically:

`FileExplorerExtensions.dll`

`FileExplorerManaged.dll`

The next useful diagnostic would likely be a trace of `ShellHost.exe` / Explorer activation, AppExtension resolution, or Windows App SDK activation rather than additional conventional CLSID or module checks.

I am particularly interested in determining whether there is a supported way to observe the AppExtension/ShellHost activation decision and identify whether the FileExp components are being rejected, skipped, or simply never requested.

# 

Update (revision 3): Windows 11 File Explorer Investigation

• Date: 2026-09-30 Supersedes: revisions 1 and 2. This version contains no commands or code. Tests are described in plain words. Method rule: Diagnostics were read-only unless listed in section 9. Nothing was repaired, re-registered, replaced, or reconfigured.

  1. Status in brief

  • A functional defect is reported: the Explorer Home page shows a blank window, default apps for file types cannot be changed, and other Explorer elements are broken. A freshly created local account shows the same symptoms, so per-user profile state is effectively ruled out. The cause is machine-wide or build-level.
  • Ruled out: system-file corruption, component-store corruption, FileExp package registration, the Windows App SDK dependency, event-log rollover, and the OS/component version-numbering mismatch (now explained).
  • Not clean: Windhawk is still active on this machine (section 5.6). The original report's "clean-state" results cannot be relied on.
  • Cause not identified. No log records an Explorer or Settings error during reproduction, so the failure appears silent. The next decisive steps are a machine-wide configuration inventory, a verified clean boot, and Process Monitor recordings of the failing actions (section 8).

  2. System and build

  	Item	Value
  	Device	ASUS ROG Strix G16 (2023), G614JV; Intel Core i7-13650HX; NVIDIA RTX 4060; 16 GB RAM
  	Windows version	26H2, build 26300, update revision 9550 (26300.9550)
  	Product name shown in registry	"Windows 10 Pro" (the same label appears on another 26H2 machine in a Microsoft Q&A thread)
  	Build lab string	26100.1.amd64fre.ge_release.240331-1435
  	DISM	tool 10.0.26100.9549; image version 10.0.26300.9550 (the original report recorded 26300.9539)
  	Installed hotfixes	KB5121794 (9/30, unidentified); KB5124010, KB5124009, KB5054156, KB5126052 (all 9/24). Dates only, no times.

  The numbering mismatch is explained. Per the Windows Insider blog, 26H2 is delivered as an enablement package on the same servicing branch as 24H2 and 25H2, and KB5124010 was released for 26100.9550, 26200.9550 and 26300.9550 together. A 26300 OS build alongside 26100.x components is expected. The frozen build lab string is consistent with the shared base (my inference).

  3. Reported symptoms

  	Symptom	Detail known
  	Home page	Blank window (whether it ever populates or hangs: not reported)
  	Default apps for file types	Cannot change (whether Settings fails to load, ignores the click, or shows an error: not reported)
  	Other Explorer elements	"Broken", unspecified
  	Fresh local account	Same symptoms

  The user states the problem was present before the update referred to as "4010" (KB5124010, dated 9/24 by the hotfix list). When the symptoms began relative to the move to 26H2 is not known.

  4. Findings carried forward from the original report

  • explorer.exe (file version 10.0.26100.8117) is byte-identical to the WinSxS copy (same SHA-256 hash).
  • The MicrosoftWindows.Client.FileExp package, version 1000.26100.10.0, is present with status Ok. FileExplorerExtensions.dll (2608.25001.0.0) and FileExplorerManaged.dll (10.0.26100.9549) exist in the SystemApps folder.
  • Its manifest registers modern Explorer extension points and targets WinUI 3 / Windows App SDK (CBS.1.6).
  • Feature 49682398 is enabled (ImageOverride, priority 15). It was not changed.
  • ShellHost.exe has Microsoft.UI.Xaml.dll (from the CBS package) and windowsudk.shellcommon.dll loaded.
  • No FileExp events were seen in the AppModel-Runtime/Admin or Shell-Core/Operational logs.
  Caveat: several of these checks were reported as clean-state after Windhawk removal. Section 5.6 contradicts that, so the "FileExp DLLs never load" finding is not a clean-state result.

  5. New findings

  5.1 Package registration and dependency

  • FileExp is Installed for SYSTEM and both user profiles (1001 "A-PC" and 1002). It is not merely staged. Its Dependencies list is empty, which is inconclusive because I cannot verify whether the inbox package declares any.
  • Microsoft.WindowsAppRuntime.CBS.1.6 (6000.900.156.100) is Installed, with three Installed user entries. The user-ID column printed a type name, so which accounts those are is unconfirmed.
  • Other runtimes present: CBS.2 2.4.1.100; 1.5 (5001.373.1736.0); 1.7 (7000.785.2325.0, staged); 1.8 (8000.994.2142.0); 2 (2.2.0.0 staged, 2.5.1.0 installed for user 1001). Duplicate rows are most likely x64/x86 variants (inference).

  5.2 AppXDeployment-Server/Operational log

  • The log is circular, 5 MB maximum, 69,632 bytes used, 16 records, not full. Rollover is ruled out.
  • All 16 records concern Windows App SDK runtimes. None mention FileExp.

  	When	Event
  	9/24 6:06:44 PM (first record)	CBS.2 2.4.1.100 installed
  	9/25 4:35 PM	1.8 8000.994.2142 installed (x64, x86)
  	9/26	1.8 8000.946.1701 removed (x64, x86)

  • The log starts on the same day as four hotfixes (9/24). That fits a reset during servicing (inference, not proven). A check for a "log cleared" event in the System log returned nothing.
  • On the user's timeline these events post-date the symptoms, so they are unlikely to be the origin.

  5.3 Integrity checks

  • System File Checker in verify-only mode: no integrity violations.
  • DISM component store health scan: no corruption detected.
  • Neither examines AppX registration state, per-user data, or third-party additions. They rule out the file-repair path only.

  5.4 ETW image-load traces

  • Trace 1: six matches for the terms FileExplorer / FileExp, all inbox System32 DLLs (Windows.FileExplorer.Common.dll, Windows.UI.FileExplorer.dll). No package DLLs.
  • Trace 2: the positive control, shell32.dll, appeared 29 times, so the method is valid. No match for FileExplorerExtensions, FileExplorerManaged, or the FileExp package folder.
  • Limits: failed load attempts leave no ETW record, so "never requested" cannot be separated from "requested and failed". Whether manual interactions occurred during either trace is unconfirmed.
  • The trace also recorded Windhawk's engine and mods loading, so it is not a clean-state capture.

  5.5 Differential event-log capture during reproduction

  Only seven channels recorded events:

  	Channel	Events	Assessment
  	PowerShell/Operational	208	Likely the user's own commands
  	Security (event 5379: 63, event 4797: 4)	67	Credential reads and blank-password queries; trigger unknown
  	Intel-IGS-Logs/Service	20	Error 14 repeating about every 5 seconds throughout, not caused by the test; the Intel Arc package status is Ok
  	LiveId/Operational	6	Token requests plus two errors (event 2028, missing file); unlikely relevant
  	System (event 1808)	1	Secure Boot certificate/key update notice
  	OAlerts, TerminalServices-LocalSessionManager	1 each	Office and session noise

  • No events in Application (so no crash or hang records), Shell-Core, AppModel-Runtime, AppXDeployment, or any Settings- or Windows App Runtime-named channel.
  • Interpretation: the failure appears silent, with no crash and no logged error. A second pasted capture had identical counts and is treated as the same run.

  5.6 Third-party injection (Windhawk still active)

  Live process inspection with signature checks (Settings was not running, so SystemSettings.exe was not covered):

  	Process	Non-Microsoft modules
  	explorer	Windhawk engine 1.7.3; Windhawk mods taskbar-dock-animation, explorer-details-better-file-sizes, file-operation-styler, windows-11-taskbar-styler; RTSSHooks64 (RivaTuner); IDMShellExt64 and IDMNetMon64 (Internet Download Manager)
  	ShellHost	Windhawk engine; Windhawk mod explorer-details-better-file-sizes; RTSSHooks64

  • The Windhawk service is Running with startup type Automatic. Two Windhawk processes are running (ID and path not displayed). No scheduled task matched.
  • "NotSigned" on the mods is expected for locally compiled Windhawk mods (my understanding).
  • No dxgi.dll exists in the Windows folder.
  • The original report's statement that Windhawk was removed from runtime is contradicted.
  • A test of stopping the service and rebooting was proposed. The user reported "no use" but supplied no verification output, so the result is unverified: it is not known whether the Windhawk engine was absent during the retest.

  5.7 Default-app write test (.txt)

  • The .txt user choice is a packaged-app entry that resolves to Notepad (Microsoft.WindowsNotepad 11.2607.14.0), with a stored hash.
  • The value was identical before and after the attempted change. This is inconclusive: what the Open with dialog did, and which app was chosen, was not reported.

  5.8 External reports

  • Sources reviewed list known issues for 26300.9550 in other areas (for example Credential Guard secure-channel loss). I found none reporting a blank Home page or default-app failure. These are forum aggregators, so absence is weak evidence.
  • One Microsoft Q&A thread reports Explorer losing its modern interface and tabs after build 26300.9539, persisting on a new local account. It is a single unverified report with a different symptom.
  • KB5124010 release notes describe Home-page behavior changes (remembering collapsed and expanded sections). The user's timeline places the symptoms before that update.

  6. Corrections and retractions

  1. Windhawk "eliminated": retracted. It is loaded in explorer and ShellHost (5.6).
  2. Log rollover as an explanation: retracted (5.2). The log started 9/24, most likely from a servicing reset.
  3. A Process Monitor path filter using only "FileExp": too broad, because it also matches inbox System32 DLLs. Use the three specific filters in section 8.
  4. The first ETW test: ran straight through without pausing for manual interactions (my layout error).
  5. Version mismatch (26300 vs 26100.x): no longer an open anomaly (section 2).
  6. My first module filter skipped the Windows folder: it would have missed a DLL placed there. The follow-up check covered that.

  7. Hypothesis status

  	Hypothesis	Status
  	System-file or component-store corruption	Ruled out
  	Package unregistered, staged-only, or missing for the user	Ruled out
  	Windows App SDK runtime (CBS.1.6) absent	Ruled out
  	Event-log rollover	Ruled out
  	Version-numbering mismatch as a fault	Explained; not abnormal
  	Per-user profile or registry-hive state	Ruled out (fresh account fails identically)
  	Windhawk / RTSS / IDM injection (machine-wide)	Open, not verifiably eliminated
  	Machine-wide policy, feature-store override, or tweak-tool change	Open, inventory not yet done
  	Shared XAML / Windows App SDK fault	Open
  	Build-level regression in 26H2	Open, rests on one unverified report
  	FileExp DLLs are supposed to load on this build	Unknown, needs a same-build baseline
  	Never requested vs. requested-and-failing (FileExp)	Open, needs Process Monitor

  8. Recommended next steps, in order

  1. Machine-wide configuration inventory (read-only). Export and review: the Windows feature-store override settings; machine and user policy settings; any Image File Execution Options entries for explorer, SystemSettings or ShellHost; the AppInit DLL setting; and any installed package whose status is not Ok. Look for anything not intentionally set, especially policies about Explorer, System, or Settings pages. 2. Verified clean boot. Use the System Configuration tool to hide Microsoft services and disable all others, disable startup items, and reboot. Open Settings on Default apps, then confirm that no Windhawk, RivaTuner or Internet Download Manager modules appear inside explorer, ShellHost or SystemSettings. Only then retest both symptoms. If the symptoms vanish, re-enable services in halves to find the cause. 3. Process Monitor on the default-app write (run as administrator, symbols configured). Filter on paths containing the .txt file-association registry key, with no process filter. Change .txt to a different app with "Always", then record the process, operation, and result for each row.
  • No rows: the fault is above the registry (in the UI or dispatch layer).
  • A write followed by a revert: note which process reverts it.
  • Access denied: a protection or policy layer is involved; open the Stack tab.
  4. Process Monitor on the blank Home page. Filter on paths containing the FileExp package folder name, FileExplorerExtensions, or FileExplorerManaged. Separately, filter explorer.exe with a result of access denied. Use Stack Summary. Repeat with boot logging if the live capture is empty. 5. Baseline. Install a Hyper-V virtual machine from a 26H2 ISO and update it to 26300.9550. Working there points to this machine's configuration; failing there points to a build regression. 6. Escalation. File a Feedback Hub report (Desktop Environment > File Explorer, using "Recreate my problem") and attach the trace files listed in section 9. Workaround for Home only: set "Open File Explorer to" to This PC in Folder Options. There is no verified workaround for default apps. Held back until evidence justifies it: file-repair scans that modify the system, package re-registration, uninstalling KB5124010 (the symptoms predate it), and blanket feature-store resets. An in-place repair install (keep files and apps, using an ISO of build 26300.9550 or newer) is the fallback. It would not fix a build-level regression.

  9. Changes made to the system

  • Explorer was ended and relaunched several times.
  • Two ETW trace sessions were created and stopped. Their output files remain at the root of drive C (two trace files and two exported text files).
  • A Windows Error Reporting local-dump setting was created, then removed. A dump folder on drive C was created and may remain.
  • A fresh local test account was created for the profile test.
  • Whether the Windhawk service was stopped or its startup type changed is not confirmed.
  • No packages, features (including 49682398), manifests, policies, or system files were modified.

  10. Open questions

  1. When did the symptoms first appear: before the move to 26H2, at the move, or after?
  2. What is the exact failure mode of each symptom (does Settings load but ignore "Set default", crash, or show nothing; does Home ever populate)?
  3. What did the Open with > Always attempt on .txt do, and which app was chosen?
  4. Was the Windhawk service actually stopped, and was its engine absent after the reboot?
  5. What is KB5121794, and was it installed by the user today?

  Sources consulted

  • Windows Insider Blog: "Releasing Windows 11, version 26H2 to the Release Preview Channel"
  • Microsoft Q&A: "old explorer without tabs option after windows 26H2 26300.9539 update"
  • WinUpdated (KB5124010) and the WindowsForum 26300.9550 build page, both aggregator sources