Windows 11 25H2: Clicking a thumbnail in a grouped taskbar button may fail to activate the selected window when two processes share an AppUserModelID

Question

Problem description

We are investigating a Windows taskbar activation issue involving two applications belonging to the same desktop product:

Application A: an Electron-based desktop application

Application B: a native Win32 application launched by Application A

Both processes intentionally use the same AppUserModelID. Windows therefore groups their top-level windows under one pinned taskbar icon and displays separate thumbnail previews.

On one Windows 11 machine, the following intermittent problem occurs:

Maximize the native Win32 application.

Start a normal application session that includes continuously rendered content.

Leave the application running for some time.

Move the pointer over the grouped taskbar icon.

Move the pointer over the Electron application’s thumbnail.

Windows Peek correctly displays the Electron window on the screen.

Click that thumbnail.

The selected Electron window does not reliably come to or remain in the foreground. The previously visible application or window remains in front.

Because Peek displays the correct window, DWM/Explorer appears to identify the selected thumbnail correctly. The problem seems to occur during or immediately after activation.

The issue has currently been reproduced on only one machine. Other tested Windows machines have not reproduced it.

Expected behavior

Clicking the Electron application’s thumbnail should activate its top-level window and bring it in front of the maximized native application.

Actual behavior

Hovering over the thumbnail shows the correct window through Windows Peek, but clicking the same thumbnail sometimes does not bring that window to the foreground.

Repeated clicks may continue to fail.

Environment

OS: Windows 11 Pro 25H2
Native OS build: 10.0.26200.8655
Build branch: ge_release

Session: Local console, session 1
RDP: No

Explorer:
  Process: explorer.exe
  File version: 10.0.26100.8117

ShellExperienceHost:
  File version: 10.0.26100.8521
  Package version: 10.0.26100.8115

Windows Client Core package:
  1000.26100.94.0

ForegroundLockTimeout:
  200000 ms

ForegroundFlashCount:
  7

CPU:
  Intel Core Ultra 5 125H

GPU:
  Intel integrated graphics
  Driver version: 32.0.101.8517

Display:
  One primary display
  Resolution: 1280 × 800
  Work area: 1280 × 752
  DPI scaling: 100%

Application configuration

The two applications run in separate processes:

One Electron process

One native Win32 process

Both processes intentionally use the same AppUserModelID as the pinned taskbar shortcut.

The Electron process sets the AppUserModelID during initialization. It also passes the same value to the native process, which calls SetCurrentProcessExplicitAppUserModelID() before creating its main UI.

A live property-store query did not find a window-level System.AppUserModel.ID override on either main HWND. The grouping therefore appears to be based on the shared process-level and shortcut-level AppUserModelID.

Window state observed during reproduction

Both main windows were:

Visible

Enabled

Responsive to WM_NULL

Not reported as hung

Not DWM-cloaked

Not WS_EX_TOPMOST

Not WS_EX_NOACTIVATE

Top-level windows without owners

The native window was maximized and covered almost the entire monitor work area.

During taskbar interaction, foreground transitions involving the Windows 11 taskbar host were observed:

Process: explorer.exe
Window class: XamlExplorerHostIslandWindow

After some transitions, the foreground returned to the previously visible application instead of remaining on the thumbnail selected by the user.

No relevant warning or error was found in the Application, System, or Shell-Core event logs around the reproduction period.

Questions for Microsoft

Is sharing one AppUserModelID between an Electron process and a separate native Win32 process a fully supported taskbar-grouping configuration on Windows 11 25H2?

When a taskbar group contains top-level windows from different processes, how does Explorer select and activate the HWND associated with the clicked thumbnail?

Can a maximized window in the same AppUserModelID group affect the activation of another group member when neither window has WS_EX_TOPMOST?

Does the Windows 11 taskbar activate the selected thumbnail HWND directly, or can it redirect activation through a root-owner or last-active-popup window?

Are there known issues in Windows 11 build 26200.8655 or Explorer 10.0.26100.8117 involving grouped taskbar windows from different processes?

Is ForegroundLockTimeout=200000 relevant when activation is initiated directly through an Explorer taskbar-thumbnail click, or should Explorer already have foreground permission?

Which ETW providers and keywords should be captured to identify:

The thumbnail HWND selected by the user

The AppUserModelID group resolved by Explorer

 The HWND Explorer attempted to activate


 
    Whether activation was rejected or redirected


    
       Why foreground returned to the previous application


       
       Is assigning the native process a separate AppUserModelID the recommended design, or should this cross-process grouping work reliably?

Current assessment

We have not concluded that this is a Windows defect.

The available evidence indicates that the failure occurs in a grouped-taskbar scenario involving:

Two separate processes sharing one AppUserModelID

One maximized native Win32 window

Selection of another process’s thumbnail

Explorer/XAML taskbar foreground transitions

We would appreciate guidance on the expected Shell behavior and the appropriate ETW trace required to identify the exact activation failure point.

Answer 1

Hi Leon Xu,

I can understand why you're investigating this as a possible Shell issue. Based on your description, Windows Peek is consistently identifying the correct Electron window, which makes it reasonable to suspect that the failure is happening at the activation or foreground-transition stage rather than during thumbnail resolution itself. However, there's a few things I need to clarify upfront here so you can have correct expectations going forwards and find the answers you need:

1. Microsoft Q&A is just a community support forum. The contributors here, including moderators and external staff, are fellow users, who share suggestions for technical issues based on official documents and their experience.
2. Your issue gets into internal Explorer/taskbar implementation details that are not publicly documented. Microsoft does not generally publish the exact activation algorithm used by the Windows 11 taskbar, nor the internal ETW event mappings for every foreground transition path.
3. Because of that, while posting here may help attract others who observed similar behavior or have the same queries, it is unlikely that the thread itself will be reviewed by the responsible engineering team. Realistically, I don't think anyone here can confirm your testing, answer your questions, or escalate these for further investigation.
4. Given those limitations, consider reporting this through Microsoft’s official channels:
   • Press Win + F to open Feedback Hub > submit under relevant category.
   • I recommend including the same information you provided above.
   • Also attach any logs, screenshots, videos on this (if possible).
   • Give a TL;DR on the issue for better visibility!

You can also open a support case with Microsoft Support, but this is generally not within their scope. For internal diagnostics, an escalation through a developer support channel would likely be required. I do have some thoughts, but note that this is just my assessment from the information provided, not to be confused with confirmation:

• The shared AppUserModelID design itself appears valid and supported.
• The issue does not currently look like proof of an AppUserModelID limitation.
• Since it reproduces on only one machine, I would lean toward either:
  • A machine-specific Shell / focus issue or a third-party focus interceptor.
  • An application-level focus race occurring after Explorer activates the selected window.

Overall, I would recommend against assigning separate AppUserModelIDs solely as a workaround unless there's a confirmation that cross-process grouping is the trigger. But that's unfortunately not something you likely to get from a public community forum like Microsoft Q&A. I hope you can get better answers from professionals on this.

---

If you think the answer is helpful to you, please mark this as accepted. If you have extra questions about this answer, feel free to click "Add Comment" and ask!

Note: Follow the steps in our documentation if you want to enable and receive the related email notifications for this thread.