I think I found the cause

It was due to removo AI github scripts

Breaking explorer

It seems more AI stuffs been introduced into explorer

So we should wait for better ai remover scripts without causing this problem

They make debloating harder

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

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/

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