Environment
- Command Palette standalone dev build
0.12.12365.0 (Microsoft.CommandPalette_8wekyb3d8bbwe)
- Windows 11 Pro for Workstations, build 10.0.26200
- Extension: an out-of-proc COM extension providing dock bands via
GetDockBands() ("Virtual Desktops 2.0", built on the CmdPal extension template, Shmuelie.WinRTServer as the COM host)
Steps to reproduce
- Install an extension that provides dock band items (each item's command executes on click).
- Use the dock band — clicks work (desktop switching, in this case).
- Leave the system alone for a while. At some point the host releases the idle extension: the extension receives
IExtension.Dispose(), and its out-of-proc process exits cleanly (no crash entries in the Application event log — this is the normal OOP COM lifecycle).
- Click a dock band button.
Expected behavior
The host re-activates the extension's COM class and executes the command — or, at minimum, refreshes/removes the stale band so the user isn't clicking dead buttons.
Actual behavior
The click opens the main palette window instead of running the command. The stale band keeps being rendered indefinitely, and nothing re-activates the released extension:
- dock band clicks keep opening the palette (observed repeatedly over hours);
- opening the palette and searching still shows the extension's top-level commands (served from the host's cache) even though the backing extension process is gone —
Process.GetProcessesByName on the extension executable shows no process;
- the extension process is not re-spawned by any of these interactions; only restarting the CmdPal host brings the band back to life (host start → extension activated → band works again).
Notes
Idle release itself is fine — that's the normal OOP COM server lifecycle, and our server exits when the last reference is dropped. The gap is that dock bands have no re-activation path once the host has released the extension: the band UI outlives the COM object it is bound to. Either dock band clicks should trigger re-activation of the extension, or the host should drop stale bands when it releases one.
Happy to provide more diagnostics (DebugView traces from the extension, a repro build, etc.).
Environment
0.12.12365.0(Microsoft.CommandPalette_8wekyb3d8bbwe)GetDockBands()("Virtual Desktops 2.0", built on the CmdPal extension template,Shmuelie.WinRTServeras the COM host)Steps to reproduce
IExtension.Dispose(), and its out-of-proc process exits cleanly (no crash entries in the Application event log — this is the normal OOP COM lifecycle).Expected behavior
The host re-activates the extension's COM class and executes the command — or, at minimum, refreshes/removes the stale band so the user isn't clicking dead buttons.
Actual behavior
The click opens the main palette window instead of running the command. The stale band keeps being rendered indefinitely, and nothing re-activates the released extension:
Process.GetProcessesByNameon the extension executable shows no process;Notes
Idle release itself is fine — that's the normal OOP COM server lifecycle, and our server exits when the last reference is dropped. The gap is that dock bands have no re-activation path once the host has released the extension: the band UI outlives the COM object it is bound to. Either dock band clicks should trigger re-activation of the extension, or the host should drop stale bands when it releases one.
Happy to provide more diagnostics (DebugView traces from the extension, a repro build, etc.).