explorer.exe crashes after KB5065429 is installed in Windows 10 21H2

Question

After KB5065429 (2025-09) update, explorer is crashing and dump file is generated after login.

Call stack shows below entries.

[0xb] explorer!TrayUI::_ShouldAutoHideTray+0xb1 0x301dc70 0x7ff6551ab21c

[0xc] explorer!TrayUI::SetAutoHideState+0x191bbc 0x301dcf0 0x7ff6551d418b

I can share .dmp file if needed. Please let me know if this issue was reported already and if it is fixed in any future KB.

Answer 1

Hello Joseph, Roy,

Thank you for sharing the Event Viewer logs and full memory dump.

The crash is a classic access violation (0xc0000005) caused by a null pointer dereference inside the Windows shell (Explorer.exe).

Key details from the dump analysis:

• Faulting module: explorer.exe
• Faulting function: explorer!TrayUI::_ShouldAutoHideTray
• Exception: INVALID_POINTER_READ (rcx = NULL)
• Explorer version: 10.0.19041.6691 (December 2025 ESU baseline)
• Crash timing: Happens immediately after logon while Explorer is initializing the taskbar / notification area

This confirms Explorer is crashing while evaluating Taskbar Auto‑Hide state during startup.

Recommended Mitigations (in order)

1. Disable Taskbar Auto‑Hide (Quick test – highest success rate)

1. Go to Settings → Personalization → Taskbar
2. Turn OFF “Automatically hide the taskbar”
3. Sign out and sign back in

If Explorer no longer crashes, this confirms the issue is in the TrayUI auto‑hide path.

2. Test with a new user profile

Create a temporary local user and sign in.

• If the new profile does not crash, the issue is isolated to user profile state corruption.

3. Check third‑party tray / shell extensions

Explorer crashes often show core Windows modules even when a third‑party extension is the real trigger.

Recommended:

• Perform a Clean Boot, or
• Use Autoruns / ShellExView
  • Disable non‑Microsoft shell & tray extensions
  • Reboot and test

Common offenders:

• Security software tray components
• VPN clients
• Cloud sync tools
• Screen capture or display utilities

4. Optional: Reset per‑user taskbar state (Advanced – back up first)

The crash occurs while reading taskbar layout data. Resetting it forces Explorer to rebuild defaults.

This step should only be done if steps above fail.

Please let me know if this can help you.

If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Thank you again for your patience and support!

Ivy Bui

Answer 2

Hello, I am Ivy

Thank you for your detailed update, and please accept our sincere apologies for the inconvenience and for the delay in our response. To pinpoint the cause of the Explorer.exe crash, could you please collect the following diagnostics and upload them to OneDrive?

Event Viewer crash details (Explorer.exe)

1. Press Win + R, type eventvwr.msc, press Enter.
2. Go to Windows Logs → Application.
3. Find the latest Error entry for explorer.exe (Event ID 1000).
4. Click Copy in the right pane (or Save Selected Events…) and attach:
   • Exception code (e.g., 0xc0000005)
   • Faulting module name
   • Fault offset
   • Timestamp/Report ID
   • A screenshot of the Event 1000 details is also helpful.

Enable full user‑mode crash dumps for Explorer (WER LocalDumps)

This ensures we get a full dump when Explorer crashes again.

1. Press Win + R, type regedit, press Enter.
2. Navigate to:\ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\explorer.exe
   • If LocalDumps/explorer.exe doesn’t exist, please create the keys.
3. Create/set these values:
   • DumpFolder (REG_EXPAND_SZ) → %LOCALAPPDATA%\CrashDumps
     • DumpType (DWORD) → 2 (2 = Full dump)
4. Sign out, sign back in, and reproduce the crash.
5. After the crash, a .dmp file will appear under: %LOCALAPPDATA%\CrashDumps

Optional: Capture with ProcDump (if WER dump doesn’t generate)

1. Open Admin Command Prompt.
2. Run: procdump -e -ma explorer.exe Then reproduce the crash. The resulting .dmp file will be written to the current directory.

Optional: Short ProcMon trace (to catch IO/registry just before crash)

1. Run Process Monitor (ProcMon) as admin.
2. Options → Enable Profiling Events (unchecked).
3. Filter… → Process Name is explorer.exe → Include.
4. Click Capture (Ctrl+E), reproduce the crash, then Stop capture.
5. File → Save… → select Native PML and All events.

Upload to OneDrive

Please upload the collected files to your OneDrive and share a link with edit/download permissions:

• Files to upload:
  • The Event Viewer export or screenshot for Event ID 1000
  • The Explorer full dump (.dmp) from %LOCALAPPDATA%\CrashDumps

How to share:

1. Right‑click the OneDrive folder → Share.
2. Choose Anyone with the link can view/download (or your org’s equivalent).
3. Paste the sharing URL back in your reply.

If the dump file is large, you can zip it before uploading.

Once we have the dump and logs, we’ll analyze the call stack, faulting module, and surrounding activity to determine whether this is profile/state corruption, a shell extension issue, or an OS regression tied to the September/December cumulative updates. We’ll then advise the exact remediation (e.g., ShellExtension isolation, taskbar state reset, or patch rollback/KIR guidance).

Thank you for your patience and support!

Ivy Bui