File Explorer hangs after many hours — WinDbg points to UserActivity / CoreMessaging; PublishUserActivities=0 appears to fix it

Question

File Explorer hangs after many hours — WinDbg points to UserActivity / CoreMessaging; PublishUserActivities=0 appears to fix it

Артур Гроховский 10

I would like to report a long-standing File Explorer hang that I have finally been able to investigate with Process Explorer and WinDbg.

The problem did not start with any particular Windows Insider build. It began when I bought this new PC exactly one year ago and has persisted throughout that entire year across many Insider builds.

During that time I have:

performed two completely clean installations of Windows Insider builds from scratch;
performed Windows Recovery once;
installed numerous subsequent Insider builds and updates.

None of this changed the behavior. The problem consistently returned.

Symptoms

If a File Explorer window remains open for many hours, eventually that window becomes completely unresponsive. The desktop and taskbar continue to work normally.

“Launch folder windows in a separate process” is enabled.

The hang is not associated with any obvious action. Explorer may work normally for many hours and then become unresponsive while simply remaining open.

Because this persisted across clean installations, recovery and many different builds, I eventually captured dumps of the affected explorer.exe processes and examined the wait chains and thread stacks.

What the diagnostics showed

Windows Wait Chain Traversal showed one Explorer instance waiting on another Explorer process.

The waiting Explorer thread was blocked in a synchronous COM/RPC call. Its stack included:

CCliModalLoop::BlockFn CSyncClientCall::SendReceive CClientChannel::SendReceive NdrpClientCall3 CoMarshalInterface CStdMarshal::RemoteAddRef

The thread it was waiting for in the other explorer.exe instance was blocked here:

NtWaitForMultipleObjects → CoreMessaging!MessageSession::WaitOnHandleCollection → CoreMessaging!MessageSession::ProcessPendingAlpcConnections → CoreMessaging!MessageSession::WaitOnOutboundAlpcMessages → CoreMessaging!MessageSession::OnFinalRelease

Immediately below that in the stack were:

cdprt!Microsoft::BamoImpl::BaseBamoConnectionImpl::Leave cdprt!UserActivityImpl::~UserActivityImpl twinapi_appcore!UserActivityRequestImpl::~UserActivityRequestImpl twinapi_appcore!UserActivityRequestManagerImpl::InternalRequestUserActivity twinapi_appcore!UserActivityRequestManagerImpl::RequestUserActivity

I did not see any third-party DLLs in the relevant blocking stacks.

This appears to place the hang somewhere in the Windows UserActivity / Connected Devices Platform / CoreMessaging / ALPC path. I do not claim that this identifies the root cause with certainty, but this was the blocking path visible in the dump.

Workaround / test

As an experiment I created:

HKLM\SOFTWARE\Policies\Microsoft\Windows\System\PublishUserActivities

as:

REG_DWORD = 0

and rebooted.

I then opened the same folder in File Explorer that had been used during the previous reproduction and left the Explorer window open as usual.

The window remained fully responsive for approximately 36 hours, until I had to reboot the PC for an unrelated driver update. Previously the hang normally occurred after several hours.

So far, setting PublishUserActivities=0 appears to have prevented the problem.

One 36-hour test is obviously not sufficient to prove causation, but together with the WinDbg stack it seems like a strong indication that the problem may involve the UserActivity / Connected Devices / CoreMessaging path rather than File Explorer itself.

I still have the dump files and can provide additional WinDbg output or specific thread stacks if they would be useful to Microsoft engineers.

0 comments

2 answers

Your answer

Answer 1

Update: I was able to narrow the Explorer hang down much further

I have now captured a full live kernel dump while the File Explorer folder window was actually hung, and the result is much more specific than the earlier user-mode dumps.

The hung CabinetWClass window belonged to explorer.exe PID 45932, GUI thread TID 0xAAEC. That exact GUI thread was blocked in the following path:

UserActivityRequestManagerImpl::RequestUserActivity → cdprt.dll → CoreMessaging!MessageSession::OnFinalRelease → CoreMessaging!MessageSession::WaitOnOutboundAlpcMessages

The ALPC object being waited on is Explorer handle 0xAB8.

From the kernel dump I traced that handle to an ALPC client communication port owned by Explorer. Its matching server communication port belongs to aicontext.exe PID 22948, on a CoreUI connection.

The interesting part is the state of that connection at the moment of the hang.

The Explorer client port was still open and connected — not closed, refused or disconnected — but its Main queue contained exactly one message. !alpc /m identifies it as:

LPC_CONNECTION_REPLY MessageId: 0x1DDC SequenceNumber: 1 Canceled: No Release: Yes

The message is owned by the AIContext server communication port but is queued on the Explorer client communication port. WaitingThread and ServerThread are both NULL.

The server-side AIContext communication port itself is also open and connected and has empty queues.

I then used the AIContext CoreUI connection port as a control group. At the time of the dump it had four active clients:

msedge.exe 0 -> 0 explorer.exe 0 -> 1 WINWORD.EXE 0 -> 0 Notepad.exe 0 -> 0

In other words, Explorer was the only CoreUI client with a queued message. I also inspected the Notepad client port in detail: it was open and connected, with all Main, Direct, Large, Pending and Canceled queues empty.

So the simple explanation “AIContext is hung and Explorer is waiting for it to answer” no longer fits the dump very well. The connection reply has already been generated and delivered into Explorer’s client queue.

My current interpretation is therefore narrower: this looks like a CoreMessaging/CoreUI session lifecycle or teardown problem on the Explorer side. The GUI thread enters MessageSession::OnFinalRelease, waits in WaitOnOutboundAlpcMessages, while an unconsumed LPC_CONNECTION_REPLY remains in its client queue.

I still would not call the queued reply itself the proven root cause. It may be either the trigger or a symptom of the same lifetime/race condition. But the failure is now localized much more tightly than before.

For context, this Explorer hang has survived multiple Insider builds, two clean Insider installations and Windows Recovery, so it does not look like simple profile corruption. I also previously tested PublishUserActivities=0, stopping CDPUserSvc/CDPSvc, and exiting OneDrive/Google Drive; none of those prevented or released the hang.

If Microsoft engineers are interested, I have the full kernel dump from the hung state and the corresponding Explorer/user-mode dumps.

Answer 2

Kai-H 27,645 Microsoft External Staff Moderator

Hi, Артур Гроховский

Thanks for documenting this so carefully. The wait chain and stacks make the UserActivity path worth investigating, especially since the same Explorer window stayed responsive for 36 hours with PublishUserActivities=0. That is a promising test result, but it does not yet establish the root cause.

Here are some suggestions you can try:

Keep the workaround in place for now and note whether the hang returns. PublishUserActivities=0 disables publishing of User Activities, so it is worth recording that trade-off alongside the test result. There is no need to repeat the clean installs or recovery steps you have already tried.

Report this through Feedback Hub on the affected PC. Include the Windows build, the fact that the issue has persisted across builds and clean installs, the approximate time before a hang, and the before-and-after result with the policy. Feedback Hub can collect relevant diagnostics when you report a problem.

Offer the dumps through the feedback report rather than posting them publicly. Include the wait-chain summary and the key thread stacks in the description. Check any files or screenshots for personal information before submitting them.

I cannot confirm a known fix or an engineering diagnosis from these stacks alone. The feedback report, together with the dumps and your controlled policy test, is the clearest way to get this specific hang investigated.

Артур Гроховский 10 Reputation points

2026-10-01T15:03:28.71+00:00

Hi Kai-h

Thanks. I have an important update: unfortunately, the hang has now recurred with PublishUserActivities=0, so the 36-hour result was not a fix.

The new occurrence is more informative, however. The affected File Explorer window is again blocked in essentially the same path:

UserActivity → cdprt/BAMO → CoreMessaging → WaitOnOutboundAlpcMessages

I inspected the actual wait object in WinDbg. The handle obtained from the NtWaitForMultipleObjects call resolves to an ALPC Port (!handle ... reports Type: ALPC Port).

A live Process Explorer stack taken much later still shows the same CoreMessaging → cdprt → twinapi.appcore → RPC/COM → explorerframe path, so this appears to be a persistent wait rather than a transient state captured by the dump.

I also tested terminating OneDrive and Google Drive and stopping CDPUserSvc and CDPSvc while the Explorer window was hung. None of these actions released the hang. A dump of CDPSvc taken before stopping it does not show an obvious corresponding CoreMessaging/ALPC/RPC blocked thread.

I will submit the issue through Feedback Hub with the dumps and these additional findings. At this point PublishUserActivities=0 should probably be considered diagnostically relevant, but not a workaround for the issue.