Deep UI launch delay (white window) on specific executable path - Off-line registry tweaks, HAGS, and full troubleshooting history inside

Hi everyone,

I'm facing a very specific, persistent, and frustrating performance issue on a high-end Windows 11 workstation (running 25H2 / Dev branch). One specific executable, Total Commander (TOTALCMD64.EXE), exhibits a strange UI rendering delay only when launched from its original installation directory.

Furthermore, I have been noticing an occasional overall UI sluggishness across the OS, which led me to investigate deeper into both display settings and kernel-level security filters.

Here is the complete history of what has been diagnosed and tested so far (compiled from troubleshooting sessions with both Claude and Gemini).

1. The Core Symptom​

• When launching C:\Utils\totalcmd\TOTALCMD64.EXE, the application window opens, but it remains completely blank/white for a brief moment before finally drawing the interface components.
• If I move the executable to another folder, it launches instantly without any white window.
• The twist: If I keep it in the original folder (C:\Utils\totalcmd\) but simply rename the file to TOTALCMD64_test.EXE, it launches instantly with no delay or white window.

The issue is strictly bound to the exact combination of the path and the original filename: C:\Utils\totalcmd\TOTALCMD64.EXE.

2. General OS Sluggishness & HAGS​

• To rule out global interface latency and rendering pipelines, Hardware-Accelerated GPU Scheduling (HAGS) has been completely disabled.
• Despite turning HAGS off, the overall system occasionally feels less snappy than it should, and the specific Total Commander path delay remains entirely unaffected.

3. What Has Been Tested and Ruled Out​

A. Security Filters & Recovery Mode (WinRE) Operations​

• Third-party security tools (Avast and Comodo Firewall) are installed. Folder exclusions were added to Avast, and Comodo's HIPS / Auto-Containment are disabled.
• I suspected Microsoft Defender's file system filter (WdFilter) was causing an aggressive hook or conflict on that directory.
• To bypass Windows 11 Tamper Protection, I booted into Recovery Mode (WinRE / Command Prompt), loaded the offline system hive, and forcefully disabled both WdFilter and WdBoot by setting their Start values to 4.
• The Result: Back in Windows, the registry keys are successfully locked at 0x4. However, running fltmc filters reveals that WdFilter still actively loads 11 instances. The 25HDev kernel forces it alive anyway, and the white window latency persists. A global path exclusion via PowerShell (Add-MpPreference) also failed to mitigate it.

B. Application Configuration​

• The .ini files configuration holds no dead network paths, mapped drives, or broken plugins that could trigger a timeout during initialization. The renaming trick proves the app files themselves are clean.

C. Deep Registry Scans & Compatibility Caches​

• Checked HKCU and HKLM under ...\AppCompatFlags\Layers -> No entries found for this path.
• Cleared MuiCache under HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache (a few old lines were deleted, Windows Explorer restarted, but no change).
• Using Registry Workshop, I performed a raw, full-database search (Keys, Values, and Data) for the literal string C:\Utils\totalcmd\TOTALCMD64.EXE.
• Result: Absolutely zero hits. The registry holds no trace, legacy compatibility flag, or tracking metric tied to this specific path.

The Conundrum​

Windows 11 is clearly treating C:\Utils\totalcmd\TOTALCMD64.EXE differently than C:\Utils\totalcmd\TOTALCMD64_test.EXE, yet this underlying rule, mitigation profile, or hook doesn't live in the standard registry paths or AppCompat caches.

Considering the global UI snappiness issues, could this be tied to a deeper kernel-level caching mechanism, an unlisted telemetry component, or a ghost path mitigation that survives offline registry purges? Where else should I look to force Windows to forget this specific filename/path association?

Thanks for your help!

The logical answer is Total Commander provides a manifest file, which manages run-time settings when the app runs. Manifest files are named as the app's filename + ".manifest".

By renaming TOTALCMD64.EXE to any other filename, the provided manifest file no longer applies. Try this: rename TOTALCMD64.EXE.MANIFEST to TOTALCMD64_test.EXE.MANIFEST. Does the problem repeat itself under the new filename?

If it continues the weird behavior, then you know it's caused by some loading issues.

garlin said:

The logical answer is Total Commander... caused by some loading issues.

Click to expand...

Thanks for the suggestion! I just ran the exact tests with the manifest file, and here are the results:

1. TOTALCMD64_test.EXE with the renamed manifest -> Instant / Super fast.
2. TOTALCMD64.EXE without any manifest file -> Ultra slow.
3. TOTALCMD64.EXE with its original manifest -> Ultra slow.

Conclusion: The manifest file has absolutely no effect on this behavior.

Crucial update regarding the timeline:I noticed a specific pattern with the degradation. Right after a fresh reboot, TOTALCMD64.EXE is slow, but as the hours pass, it becomes significantly worse (ultra slow).

This accumulation of latency over time heavily points towards a memory leak, handle leak, or an accumulating locking contention from whatever background process or kernel filter is hooking onto C:\Utils\totalcmd\TOTALCMD64.EXE. Meanwhile, TOTALCMD64_test.EXE bypasses this hook entirely and remains instant.

Since a full string search in the registry with Registry Workshop yielded zero results, this signature might be monitored via a file hash or a binary database (like Amcache.hve or a hidden Shim database *.sdb) that gets bloated or stuck during the session.

Any ideas on how to pinpoint which process is holding this specific path hostage and leaking over time?

@NexusFred I do believe @garlin is onto something. Windows caches manifests. Where exactly, I haven't managed to figure out. Removing or replacing the manifest file will accomplish nothing once Windows has cached the contents (or absence) of a manifest. However, moving or renaming the EXE file restores default manifest behavior.