You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the #207 readiness-gate fix removed the Outlook hookup-path STA block, a distinct, pre-existing stall remains: the startup [Startup timing] table attributes ~60-115 s to the IntelConfig phase even though IntelligenceConfig.ReadConfigurationAsync itself runs in ~130 ms. The cost is the Task.Run continuation in ApplicationGlobals.LoadSequentialAsync being unable to resume on the STA for an extended period, leaving the Outlook UI locked. This issue is a detailed-diagnostics effort to localize exactly what occupies/blocks the STA during that window and to determine whether the add-in causes it.
Environment
OS/version: Windows; Outlook desktop (outlook.exe host)
Runtime: .NET Framework (net48) Outlook VSTO add-in (TaskMaster), STA VSTA_Main thread (thread 1)
Command/flags used: Normal add-in startup; [Startup timing] and [IntelConfig timing] blocks emit on the console/Debug output path
Data source or fixture: Live Outlook/Exchange profile; the Microsoft-published Teams Meeting Add-in is present and must remain installed (it is a professionally released add-in; the workaround must be on the TaskMaster side, not by removing Teams)
Allow ApplicationGlobals.LoadAsync(false) to run the sequential startup phases.
Observe the [Startup timing] table: IntelConfig phase shows ~60-115 s wall-clock while the [IntelConfig timing] per-resource block shows the deserialize completed in ~130 ms, and the UI is unresponsive during the gap.
Expected Behavior
Startup completes well within the 60 s COM-apartment threshold with the STA continuously pumping; no phase records a multi-minute wall-clock that is not attributable to its own work; the UI stays responsive.
Actual Behavior
The IntelConfig phase wall-clock is dominated by a Task.Run continuation that cannot resume on the STA. In the 2026-06-22 post-fix capture: [IntelConfig timing] emitted at 16:41:55 (read 3.92 ms, deserialize ~130 ms), then the STA was unavailable ~16:41:57-16:43:57 (~120 s) before the next phase ran; the phase table recorded IntelConfig 1:54.99, TOTAL 2:02.02. During the gap the log shows the Teams add-in throwing many first-chance exceptions and TaskMaster's own assemblies (Swordfish, ToDoModel, the WPF stack, TaskVisualization) loading.
Summary
After the #207 readiness-gate fix removed the Outlook hookup-path STA block, a distinct, pre-existing stall remains: the startup
[Startup timing]table attributes ~60-115 s to theIntelConfigphase even thoughIntelligenceConfig.ReadConfigurationAsyncitself runs in ~130 ms. The cost is theTask.Runcontinuation inApplicationGlobals.LoadSequentialAsyncbeing unable to resume on the STA for an extended period, leaving the Outlook UI locked. This issue is a detailed-diagnostics effort to localize exactly what occupies/blocks the STA during that window and to determine whether the add-in causes it.Environment
outlook.exehost)VSTA_Mainthread (thread 1)[Startup timing]and[IntelConfig timing]blocks emit on the console/Debug output pathSteps to Reproduce
main(post-Bug: outlook-startup STA-thread COM-blocking stall (reframed from intelconfig-deserialize-stall) #207 merge) loaded.ApplicationGlobals.LoadAsync(false)to run the sequential startup phases.[Startup timing]table:IntelConfigphase shows ~60-115 s wall-clock while the[IntelConfig timing]per-resource block shows the deserialize completed in ~130 ms, and the UI is unresponsive during the gap.Expected Behavior
Startup completes well within the 60 s COM-apartment threshold with the STA continuously pumping; no phase records a multi-minute wall-clock that is not attributable to its own work; the UI stays responsive.
Actual Behavior
The
IntelConfigphase wall-clock is dominated by aTask.Runcontinuation that cannot resume on the STA. In the 2026-06-22 post-fix capture:[IntelConfig timing]emitted at 16:41:55 (read 3.92 ms, deserialize ~130 ms), then the STA was unavailable ~16:41:57-16:43:57 (~120 s) before the next phase ran; the phase table recordedIntelConfig 1:54.99,TOTAL 2:02.02. During the gap the log shows the Teams add-in throwing many first-chance exceptions and TaskMaster's own assemblies (Swordfish, ToDoModel, the WPF stack, TaskVisualization) loading.Logs / Screenshots
docs/features/active/2026-06-18-outlook-startup-intelconfig-deserialize-stall-207/evidence/diagnostics/ac12-postfix-capture-2026-06-22.mdandstartup-timing-increment3-2026-06-21.md(the stall measured 60-115 s across multiple captures, independent of and predating the Bug: outlook-startup STA-thread COM-blocking stall (reframed from intelconfig-deserialize-stall) #207 fix).Impact / Severity
Multi-minute startup unresponsiveness on affected profiles and a
ContextSwitchDeadlockMDA risk, even after the #207 hookup-path fix.Source
From: docs/features/potential/2026-06-22-outlook-startup-intelconfig-continuation-stall.md