File Explorer wont expand to folder

EtaCarinae said:

Can we get some traction on this? No one linked to any feedback hub post. Can someone please link their feedback hub post so we can upvote it?

Click to expand...

Fabler2 said:

Use CTRL+SHIFT+E as a workaround for now.

Click to expand...

dacrone said:

heres an autohotkey script (compiled exe is attached) that will reapply Expand to Open Folder via reg to keep the navigation pane expand working properly.

ahk code inside exe:

Code:

#Persistent
SetTimer, EnforceExpandToFolder, 500
return

EnforceExpandToFolder:
RegRead, currentValue, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced, NavPaneExpandToCurrentFolder
if (currentValue != 1) {
    RegWrite, REG_DWORD, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced, NavPaneExpandToCurrentFolder, 1
    ; Optional: refresh Explorer to apply change
    PostMessage, 0x111, 41504,,, ahk_class CabinetWClass
}
return

Click to expand...

tashev2078 said:

the Downloads folder does not expand when clicking it from Quick access. This is the only folder that behaves like this. Any other folder that I test works.

Click to expand...

dacrone said:

yeah its the shell. i'll write it to add those. if you pin Downloads etc to quick access it does work though. i just tested it. but i'll rewrite it to include shell so the ones in This PC folder view are expanded too.

EDIT:
fixed is attached

Click to expand...

frogSushi said:

Hi everyone,

I'll start with a confession: I registered to this forum specifically to share this solution. That's how much this bug has been driving me crazy. The original post is two years old and people were still complaining about it in late 2025 — so I know I'm not alone in this particular circle of hell.

After years of silently suffering, I decided to actually investigate. With the help of several AI assistants (shoutout to Claude and Copilot — they argued a lot but eventually got there), a hex editor, a forensic LNK parser, and more trial and error than I care to admit, we found the root cause.

The culprit: Windows 11 stopped setting a flag called DisableKnownFolderTracking in newly created shortcuts. Without it, Explorer resolves the target through the shell namespace instead of the filesystem, which completely bypasses tree expansion. Windows 10 set this flag correctly. Windows 11 doesn't.

The fix: a small Python script (Python 3, no dependencies) that patches the two affected bits directly in the shortcut's binary header. That's it — no registry hacks, no third-party tools, no "Show all folders" nuclear option.

One important caveat: set your shortcut icon before patching, and don't touch it afterwards — editing the icon via Properties rewrites the header and removes the patch.

Usage is simple:

# Patch in place
python shortcut_patcher.py "MyShortcut.lnk"

# Or patch to a new file
python shortcut_patcher.py "MyShortcut.lnk" "MyShortcut_fixed.lnk"

I'm attaching the script (shortcut_patcher.py) and instructions (shortcut_patcher.txt) in a zip file.

This is free to use, modify, and integrate into a more user-friendly tool for people who don't use Python — a GUI wrapper, a shell extension, whatever. I'd just love to know if that happens!

Hope this saves someone else a few years of frustration.

And let me know if that does work for you.

Click to expand...

LesFerch said:

I'm trying to verify this patch, but I'm not having any success.

I created a folder shortcut on my desktop that opens Downloads. As expected, it opens to Downloads, but does not expand the Navigation pane to Downloads. I then used the Python script to create a new patched shortcut and I can see, using Beyond Compare, that "9B 00" has been changed to "DB 40". However, I see no change in behavior.

I did not edit any shortcut properties after patching. The "Target" property is set to my Downloads folder. I also tested again with the "Start in" folder also set to my Downloads folder, but that made no difference. What am I missing?

Click to expand...

param(
    [Parameter(Mandatory = $false)]
    [string]$TargetPath,

    [Parameter(Mandatory = $false)]
    [string]$ShortcutPath,

    [switch]$PatchExistingOnly
)

function New-TrackedShortcut {
    param(
        [Parameter(Mandatory = $true)]
        [string]$TargetPath,

        [Parameter(Mandatory = $true)]
        [string]$ShortcutPath
    )

    # 1) Create a normal shortcut (set icon BEFORE patching if you want a custom one)
    $shell = New-Object -ComObject WScript.Shell
    $sc = $shell.CreateShortcut($ShortcutPath)
    $sc.TargetPath = $TargetPath
    $sc.WorkingDirectory = (Split-Path $TargetPath -Parent)
    # Example: set icon here if desired
    # $sc.IconLocation = "$env:SystemRoot\System32\shell32.dll,3"
    $sc.Save()

    # 2) Patch the header bits
    Patch-LnkHeader -Path $ShortcutPath
}

function Patch-LnkHeader {
    param(
        [Parameter(Mandatory = $true)]
        [string]$Path
    )

    if (-not (Test-Path $Path)) {
        Write-Warning "File not found: $Path"
        return
    }

    # Read all bytes
    $bytes = [System.IO.File]::ReadAllBytes($Path)

    $offset1 = 0x15  # first affected byte
    $offset2 = 0x16  # second affected byte

    # Bitmasks to set (OR them in)
    $mask1 = 0x10
    $mask2 = 0x02

    if ($bytes.Length -le [Math]::Max($offset1, $offset2)) {
        Write-Warning "File too small to patch: $Path"
        return
    }

    $bytes[$offset1] = $bytes[$offset1] -bor $mask1
    $bytes[$offset2] = $bytes[$offset2] -bor $mask2

    [System.IO.File]::WriteAllBytes($Path, $bytes)

    Write-Host "Patched: $Path"
}

# ----------------- Entry logic -----------------

if ($PatchExistingOnly) {
    if (-not $ShortcutPath) {
        Write-Error "When using -PatchExistingOnly, you must pass -ShortcutPath (file or folder)."
        exit 1
    }

    if (Test-Path $ShortcutPath -PathType Container) {
        Get-ChildItem -Path $ShortcutPath -Filter *.lnk -Recurse | ForEach-Object {
            Patch-LnkHeader -Path $_.FullName
        }
    }
    else {
        Patch-LnkHeader -Path $ShortcutPath
    }
}
else {
    if (-not $TargetPath -or -not $ShortcutPath) {
        Write-Error "Provide -TargetPath and -ShortcutPath, or use -PatchExistingOnly with -ShortcutPath."
        exit 1
    }

    New-TrackedShortcut -TargetPath $TargetPath -ShortcutPath $ShortcutPath
}

.\Fix-ExplorerShortcut.ps1 `
    -TargetPath "C:\Some\Folder" `
    -ShortcutPath "$env:USERPROFILE\Desktop\Some Folder.lnk"

when it tried to replace the This PC folder Downloads (shell: Downloads) with this shortcut, it no longer expands the nav pane

Click to expand...

frogSushi said:

@LesFerch You’re right — I was able to reproduce exactly what you described. I never use desktop shortcuts to folders since I never go to the desktop while working, so I hadn’t tested that scenario until now. If the shortcut is launched from the desktop, it indeed doesn’t work (the navigation pane stays on Home).
It only works when the shortcut is run from an already open File Explorer window (explorer.exe). You can even try it with the patched shortcut on your desktop: open Windows File Explorer, navigate to Desktop, then double‑click the patched shortcut — it will expand correctly.

I personally keep the shortcuts I need in a dedicated folder and pin that folder to the Quick Access area in Explorer. Do not pin shortcuts (or folders) directly into Quick Access, because those will never expand when clicked.

But even using a patched shortcut from the desktop is already far superior to using a non‑patched one. With the patched shortcut, any navigation into a subfolder of the target folder will trigger the tree expansion in the navigation pane, which never happens with a non‑patched shortcut.When using the CTRL+SHIFT+E trick after launching a patched shortcut, Explorer expands to the actual path without creating that odd extra tree that doesn’t follow your navigation.

@dacrone So the patch worked on your machine as well?

I didn’t quite understand what you meant by that… But if you modify anything in a patched shortcut, it stops working (no more expansion) and the shortcut becomes impossible to patch again. You need to patch a freshly created shortcut each time. However, you can move or rename a patched shortcut — that doesn’t cause any issues.

Click to expand...

dacrone said:

No, I replicated your python script’s functions to a powershell script. I can create the shortcuts and they work as stated, but if you use the reg or winaero tweaker to place that shortcut into the folders category in This PC, it doesn’t work anymore. That doesn’t alter the shortcut but apparently won’t read the shortcut either.. but instead read the actual path, which doesn’t expand.
I’m reworking my ahk since this has been resurrected. I’ve made a little progress with it and will continue to play with it as time permits.

Click to expand...