StartMenu.dll null-pointer crash (0xc0000005) when dragging an app out of the Start menu — Windows 11 26H2 26300.9711

Question

StartMenu.dll null-pointer crash (0xc0000005) when dragging an app out of the Start menu — Windows 11 26H2 26300.9711

寒笺落 85

Environment

Windows 11 26H2, build 26300.9711 (Pro, AMD64, zh-CN), latest cumulative update 26100.9711 installed.

Using the built-in Start menu (new "All apps" page). No third-party Start menu software.

Symptom

Press and drag any app icon in the Start menu:

dragging inside the menu works, the icon follows the pointer
as soon as the pointer leaves the Start menu boundary (or after about a second even inside), StartMenuExperienceHost crashes and the menu disappears
no error dialog is shown; the crash timing is not fixed (sometimes immediate, sometimes ~1 s)

Reproduction

Press Win to open Start, switch to "All apps"
Press and hold any app icon and start dragging
Drag for a moment or move the pointer outside the menu
The menu closes; an Application Popup (Event ID 26) and an Application Error 1000 are logged

Crash data (Event ID 1000, reproduced on 2026-10-25 02:27 and repeatedly since)

Faulting application name: StartMenuExperienceHost.exe, version 10.0.26100.9549

Faulting module name: StartMenu.dll, version 2608.26001.0.0

Exception code: 0xc0000005

Fault offset: 0x0000000000203ee1

Faulting module path: C:\WINDOWS\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\StartMenu.dll

WER minidumps (10 samples) all show the same fault address 0x7ffc4b1d3ee1 (module base 0x7ffc4afd0000), i.e. a null-pointer dereference in the drag/drop handover path. Modules loaded at crash time include DragDropExperienceDataExchangeDelegated.dll and windows.applicationmodel.datatransfer.dll.

What has been ruled out

A brand-new local account on the same machine and driver does NOT reproduce it
No third-party DLLs are loaded in StartMenuExperienceHost
Clean boot, Safe Mode, DISM /RestoreHealth, sfc /scannow: no effect
Re-registering Microsoft.Windows.StartMenuExperienceHost and MicrosoftWindows.Client.Core: no effect
Resetting the per-user AppModel registration for both packages: no effect

Known-fix question

Public reports mention that Microsoft fixed "Start menu crashes when dragging apps" in Insider Experimental build 26300.9032 (2026-07-31). This machine runs 26300.9711, which is newer, but the crash still reproduces 100%.

Questions

Is StartMenu.dll 2608.26001.0.0 +0x203ee1 a known null-dereference defect?
Has the 26300.9032 fix shipped to the 26H2 release branch? Which LCU/KB contains it?
If it is known, what is the current status? If not, can this be filed as a bug?
Do you need ETW/WPR traces? I can collect them on request.

Notes

This crash does NOT produce an Application Error 1000 by default on this system until WER logging is enabled; it only logs "Application Popup" Event ID 26. That is why it is easy to misdiagnose as "no crash".
I have already filed this through Feedback Hub.
I would like to avoid reinstalling Windows or migrating to a new user profile if possible; the profile contains a large amount of manual configuration.

User's image

0 comments

2 answers

Your answer

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 2

Kai-H 30,065 Microsoft External Staff Moderator

(Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.)

Hi, 寒笺落

Thanks for all the detail. Since a brand-new account doesn't crash, the problem most likely comes from something saved in your own profile's Start menu data that the drag code can't handle. It's not a broken system file.

To your questions: build 26300.x is an Insider Experimental build, so the 26300.9032 fix only ships through Insider flights. It doesn't get a public KB or LCU number. The release notes call it an issue that affected "some Insiders," so your case may be a similar bug that wasn't covered by that fix. I can't see internal crash data from here, so I can't confirm whether that +0x203ee1 offset is a known defect. Your Feedback Hub report is the right place to file it as a bug. For traces, open your report, choose "Recreate my problem," and drag an app until it crashes. That records the trace and attaches it for the engineers. Posting your Feedback Hub link here can also help others vote it up.

Here are some suggestions you can try:

Turn off the phone companion pane and switch the "All apps" view (Category/Grid/List) under Settings > Personalization > Start, then test dragging again.

Reset only your Start layout instead of the whole profile. End StartMenuExperienceHost.exe in Task Manager, go to %LocalAppData%\Packages\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\LocalState, copy start2.bin somewhere safe, then delete it and sign out and back in. Your pins reset, but your other settings stay. If it doesn't help, just copy the file back.

Until a fix arrives, it's recommended to right-click the app and use "Pin to taskbar" or "More > Open file location" instead of dragging.

寒笺落 85 Reputation points

2026-10-29T15:46:08.6833333+00:00
Thanks Kai-H. Updating with what has already been tested before posting:

Phone companion pane: turned off on this device all along, so that variable is excluded.

"All apps" view modes: Category, Grid and List were all tested; the crash is identical in each.

start2.bin: deleted twice (once together with the whole StartMenuExperienceHost package cache in LocalState/TempState), then signed out and back in. The crash persisted.

Feedback Hub report, trace captured with "Recreate my problem" (public, so it can be voted on):

https://aka.ms/AA14184f

Two things I'd like to confirm:

Since 26H2 / 26300.x only ships through Insider flights and this machine is not enrolled in the Insider Program, is there any supported way to receive the fixed build without enrolling? Or is joining the Experimental channel the only path?

If the +0x203ee1 crash turns out to be a different defect than the one fixed in 26300.9032, can the trace above be filed as a new bug? If so, could you confirm once it has a tracking ID?

I can stay on this build and collect any additional traces you need.
Kai-H 30,065 Reputation points Microsoft External Staff Moderator

2026-11-01T09:22:59.32+00:00

Hi, 寒笺落

Thanks for the update and for posting the Feedback Hub link. That makes it a lot easier for others to find and upvote.

26H2 isn't Insider-only. It has been a regular public release since September 29, and 26300.9711 is the October security update KB5127648. That means you don't have to join the Experimental channel. A fix from an Insider build usually comes to regular releases later through normal updates. There's no public KB that maps to the 26300.9032 fix, though.

Install the newest 26H2 update, the October 28 optional preview KB5127936 (build 26300.9818). Go to Settings > Windows Update, turn on "Get the latest updates as soon as they're available," then check for updates. You can also download it from the Microsoft Update Catalog. Then test dragging again.

If it still crashes on 26300.9818, add a comment to your Feedback Hub report with the new build number and a fresh "Recreate my problem" capture. That shows the engineers the bug is still there on the latest release.

On your second question, forum responders can't file internal bugs or see tracking IDs. Your Feedback Hub report is the official bug report. If engineers pick it up, its status will change right there in Feedback Hub. You can also keep an eye on the 26H2 known issues page. This crash isn't listed there yet.
寒笺落 85 Reputation points

2026-11-01T14:31:54.82+00:00

Updated: KB5127936 (build 26300.9818) installed today, and the crash still reproduces.

Event ID 1000 at 2026-11-01 21:18:39 and 21:21:55:

StartMenuExperienceHost.exe 10.0.26100.9818

StartMenu.dll 2609.14000.0.0

0xc0000005 at offset 0xd9a60

The module version changed (previously 2608.26001.0.0 / offset 0x203ee1), so the preview did update

the binary, but the defect remains at a new offset. The new build and a fresh trace are attached

to the Feedback Hub report.

Should this still be treated as an open defect? Is there a newer preview build I should try?
Kai-H 30,065 Reputation points Microsoft External Staff Moderator

2026-11-02T08:17:18.5933333+00:00

Hi, 寒笺落

Thanks for testing the preview so quickly. Yes, I'd still treat this as an open defect. The StartMenu.dll binary changed and it still crashes the same way, so the bug made it into the new code. It's also not on the 26H2 known issues page yet. KB5127936 (26300.9818) is the newest 26H2 build right now. The next update is the November 10 security release.

Here are some suggestions you can try in the meantime:

In your earlier thread you mentioned the crash started after a third-party context menu tool changed a taskbar pinning setting. Dragging an app out of Start is how you pin it to the taskbar, so that tool may have left a setting behind in your profile. That would explain why a new account works fine. Open Registry Editor and check these two keys for leftover values like NoPinningToTaskbar or TaskbarNoPinnedList, then compare them with the same keys in the test account: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

If nothing looks off there, export and then delete HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband and restart Explorer. This resets only your taskbar pins, and you can import the export file to bring them back.

If either step fixes it, please add a note to your Feedback Hub report. It will help the engineers track down the cause.
寒笺落 85 Reputation points

2026-11-02T08:30:10.08+00:00
Thanks Kai-H. I tested both suggestions today, and neither changed the behaviour.

1. Leftover policy values

The policy keys did contain a leftover value from the third-party tool:

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer -> NoChangeStartMenu = 1 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer -> NoChangeStartMenu = 1

NoPinningToTaskbar / TaskbarNoPinnedList were not present.

I removed both NoChangeStartMenu values, restarted Explorer, and tested dragging three times. The crash still occurred.

2. Taskband

Exported the Taskband key to a .reg backup, deleted it, restarted Explorer, tested again. Still crashes.

Both values have been restored to their previous state afterwards.

Event log for the latest attempts (8 crashes, 2026-11-02 16:25:50 - 16:27:19), all identical:

StartMenu.dll 2609.14000.0.0, exception 0xc0000005, fault offset 0xd9a60

So the leftover pinning policy and the Taskband data are both excluded.

Should I just wait for the November 10 security update, or is anything else worth collecting before then? I can keep the Feedback Hub report updated with each new build.
Kai-H 30,065 Reputation points Microsoft External Staff Moderator

2026-11-02T08:52:12.42+00:00

Hi, 寒笺落

Thanks for checking those so carefully. That NoChangeStartMenu value is actually the best lead so far. It's the policy behind "Remove drag-and-drop and context menus on the Start Menu," and it stops you from dragging items in Start. The new Start menu probably still lets the drag begin and then crashes when the policy blocks it. That would also explain why your new test account works fine.

Delete NoChangeStartMenu from both keys again, but don't restore it this time. Restarting Explorer probably isn't enough to apply this kind of policy change, so do a full restart and then test dragging.

If the value comes back after restarting, the tool probably set it through Local Group Policy. Open gpedit.msc and go to User Configuration > Administrative Templates > Start Menu and Taskbar. Set "Remove Drag-and-drop and context menus on the Start Menu" to Not Configured. Then run gpupdate /force and restart.

If dragging works after that, you have your fix. Either way, add the NoChangeStartMenu detail to your Feedback Hub report. Start shouldn't crash even when this policy is turned on, and this gives the engineers an easy way to reproduce it. Waiting for the November 10 update is fine. You don't need to collect anything else.
寒笺落 85 Reputation points

2026-11-02T09:05:10.15+00:00
Follow-up: NoChangeStartMenu removed completely, tested after a full restart.

Actions taken

Stopped the third-party tool's service and set it to Manual so it could not re-apply the policy.

Deleted NoChangeStartMenu from both HKCU and HKLM.

Did a full restart (not just an Explorer restart).

Verified after reboot: both values absent, service stopped.

Result

I tested three times, and it crashed on every attempt, with an identical signature:

StartMenu.dll 2609.14000.0.0, exception 0xc0000005, fault offset 0xd9a60

Attempts at 17:02:39, 17:03:06 and 17:03:44. So the drag-and-drop policy is excluded as well.

Additional observation

During the same session DataExchangeHost.exe also crashed once (17:04:23). That process is involved in the Start menu to taskbar drag handover, so it may share the same root cause.

I have added this to the Feedback Hub report. Waiting for the November 10 update.
Kai-H 30,065 Reputation points Microsoft External Staff Moderator

2026-11-03T08:37:17.84+00:00

Hi, 寒笺落

Thanks for testing this so carefully. With the policy removed from both hives, the service stopped and a full reboot, NoChangeStartMenu is clearly not the cause. The crash signature is also identical every time (same StartMenu.dll build, 0xc0000005, offset 0xd9a60). That points to a specific bug in that code path rather than something random in your environment. The DataExchangeHost.exe crash fits that too, since it handles the drag handover.

Before November 10, these checks would help narrow it down:

Uninstall the third-party tool completely and reboot. Stopping its service doesn't stop any DLLs it may inject into Explorer or StartMenuExperienceHost. Many Start and taskbar customizers hook those processes directly. If the crash stops after uninstalling, that's your answer.

Try a fresh local user account. Create a new local account and test the same drag. If it works there, the problem is in your profile's Start layout data, not the system.

Capture a full crash dump for the Feedback Hub report. Go to HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\StartMenuExperienceHost.exe and set these values:

DumpType (DWORD) = 2

DumpFolder (Expandable String) = something like C:\Dumps

Reproduce the crash once, then attach the .dmp file to your Feedback Hub item. A dump is far more useful to the engineers than the event log entry alone.

Workaround in the meantime: Right-click the app in Start and choose "Pin to taskbar" instead of dragging. That skips the drag handover, so it should avoid the crash.

If the crash still happens after the November update, post the new StartMenu.dll version here so others can tell whether it was addressed.
寒笺落 85 Reputation points

2026-11-03T16:35:51.3933333+00:00
Full crash dump captured (DumpType=2, build 26300.9818), zipped 185 MB:

https://1drv.ms/u/c/2d5c2c38aef41eab/IQBKfUsaaneuR4teOyMvWsvKAXnzJ77W0DduTKyeN9lM7XM?e=xiKF1P

Exception

0xc0000005, read at address 0x0 (null dereference) StartMenu.dll 2609.14000.0.0 + 0xd9a60

Faulting instruction

At +0xd9a60: 48 8B 01 (mov rax, [rcx]) with rcx = 0, then 48 8B 40 30 (mov rax, [rax+0x30]) and FF 25 (jmp through the CFG dispatch pointer). That is a virtual-call thunk, so the code performs a virtual method call on a null object.

Approximate call chain (stack walk, no symbols)

StartMenu.dll+0xd9a60 (fault) StartMenu.dll+0xdf5bd StartMenu.dll+0x1552cb StartMenu.dll+0xae24e StartMenu.dll+0x21cf58 StartMenu.dll+0x21b716 Windows.UI.Xaml.dll+0xe5f68 ... XAML / CoreMessaging message loop

Thread and modules

The faulting thread is the XAML UI thread. Loaded modules include DragDropExperienceDataExchangeDelegated.dll, windows.applicationmodel.datatransfer.dll, StartMenu.NET.dll and dcomp.dll. The XAML frames are only the message loop, so the defect is inside StartMenu.dll's drag handler dispatching through a null interface.

On your three suggestions

Uninstalling the tool: I did not run the uninstaller, because the evidence already excludes it. Stopping its service and removing its policy had no effect, and the running StartMenuExperienceHost loads 142 modules, all under C:\Windows, so no third-party DLL is injected into it. I am confident a full uninstall would not change the result. If you want it as a formal control test, say so and I will do it.

Fresh local account: already covered before posting - it does not reproduce.

Full dump: done, link above.

I will retest after the November 10 update and post the new StartMenu.dll version.