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

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.

# 

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