PowerShell 7 Taking 30+ Seconds to Open After Windows Update — Root Cause Found

A deep-dive diagnostic that led to an unexpected culprit: a corrupted Windows Terminal COM registration.

The Symptoms

After a Windows Update (KB5089549 / KB5087051, installed May 21, 2026), PowerShell 7 started taking 30–35 seconds to open — every single time, from any launcher: Win+R, Start Menu, Command Prompt, double-clicking pwsh.exe directly.

At the same time, Unicode characters in terminal tools (like Claude Code's ⏵⏵ status indicators) started showing as blank squares.

These seemed like two separate problems. They weren't.

What We Ruled Out

Before finding the real cause, we went through the usual suspects — all of which turned out to be dead ends:

Hypothesis	Test	Result
Heavy `$PROFILE`	`pwsh -NoProfile` from Win+R	Still 34s
Network paths in `$PATH`	`$env:PATH -split ';' \	Where-Object { $_ -like '\*' }`
Windows Defender scanning	Added exclusion for `C:\Program Files\PowerShell\7`	No change
SmartScreen / CRL check	Tested in Airplane Mode	Still 34s
Smart App Control	Checked Windows Security	Disabled
Memory Integrity (HVCI)	Checked Core Isolation settings	Disabled
Third-party antivirus	None installed	N/A
Store app (AppX) overhead	Installed MSI version instead	Still 34s
Windows Defender (full)	Disabled real-time protection entirely	Still 34s

Every classic explanation failed. Time for deeper tooling.

The Diagnostic: Process Monitor

Using Sysinternals Process Monitor (ProcMon), we captured all activity during a slow pwsh.exe launch and filtered by the process name.

The log revealed a striking pattern:

10:53:10  pwsh.exe   Thread Create       ← process starts
10:53:10  pwsh.exe   Load Image ntdll.dll
10:53:10  pwsh.exe   Load Image kernel32.dll
10:53:10  pwsh.exe   Load Image KernelBase.dll
10:53:10  pwsh.exe   Process Create → conhost.exe (PID 22716)
            ← NO ACTIVITY FOR 35 SECONDS →
10:53:45  pwsh.exe   Load Image sechost.dll
10:53:45  pwsh.exe   Load Image rpcrt4.dll
10:53:45  pwsh.exe   Load Image imm32.dll
            ← normal startup continues →

35 seconds of complete silence — no file I/O, no registry reads, no network calls. The process was alive (visible in Process Profiling entries) but fully blocked on something in memory.

Following the conhost Trail

The last operation before the freeze was pwsh.exe creating conhost.exe with PID 22716:

pwsh.exe → Process Create → \??\C:\WINDOWS\system32\conhost.exe 0xffffffff -ForceV1

Switching the ProcMon filter to conhost PID 22716 revealed exactly what it was doing during those 35 seconds:

HKCR\PackagedCom\Package\
  Microsoft.WindowsTerminal_1.24.11321.0_x64__8wekyb3d8bbwe\
    Server\0\ApplicationId        → "App"
    Server\0\DisplayName          → "OpenConsole"
    Server\0\Executable           → "OpenConsole.exe"
    Server\0\RuntimeBehavior      → 1
    ...

conhost was trying to activate Windows Terminal as its console host via COM. It found the package registration in the registry (HKCR\PackagedCom\Package\Microsoft.WindowsTerminal_*), attempted to activate OpenConsole.exe, got no response — and waited 35 seconds for the COM activation to timeout before falling back to legacy conhost mode.

The Root Cause

The Windows Update had corrupted the Windows Terminal package. The app appeared as "Installed" in the Microsoft Store, but the actual package was broken — OpenConsole.exe could not be activated.

This created a hidden failure loop:

Any console app starts (pwsh, cmd, etc.)
  → Windows creates conhost.exe
  → conhost checks for a registered terminal server
  → Finds Windows Terminal (Microsoft.WindowsTerminal_1.24.11321.0) in PackagedCom registry
  → Attempts COM activation of OpenConsole.exe
  → Package is broken → activation hangs
  → 35-second COM timeout fires
  → Falls back to legacy V1 conhost
  → Console app finally gets its window

This affected every console application on the system — not just PowerShell.

The Unicode rendering issue was a side effect: because Windows Terminal (which handles font fallback gracefully) was unavailable, the user was stuck with legacy conhost, which has no font fallback and can't render glyphs like ⏵ (U+23F5) that aren't explicitly in the configured font.

The Fix

Quick workaround (stops the timeout immediately):

Settings → System → For Developers → Terminal → change from "Windows Terminal" to "Windows Console Host"

This tells conhost not to attempt Windows Terminal delegation, eliminating the 35-second COM timeout instantly.

Permanent fix (reinstall Windows Terminal cleanly):

# Remove the corrupted package
Get-AppxPackage -Name Microsoft.WindowsTerminal | Remove-AppxPackage

# Reinstall via winget
winget install --id Microsoft.WindowsTerminal -e

Then go back to Settings → System → For Developers → Terminal and set it back to Windows Terminal.

Result: PowerShell opens in under 1 second, Unicode renders correctly, everything back to normal.

Key Takeaways

1. ProcMon is indispensable for startup timing issues.
When all the usual suspects (Defender, SmartScreen, profile, PATH) are ruled out, the only way to find a 35-second gap with zero I/O is to look at the actual event trace.

2. "Installed" doesn't mean "working."
The Microsoft Store reported Windows Terminal as installed. The COM registration was intact. But the package was functionally broken. No UI-level tool would have surfaced this.

3. conhost delegates to Windows Terminal on every console app launch.
This is by design — it's how Windows Terminal integrates transparently with any console application. But it means a broken Windows Terminal silently degrades every console app on the system, not just Terminal itself.

4. Two seemingly unrelated symptoms, one root cause.
Slow startup and broken Unicode looked like separate issues. They were the same corrupted package viewed from different angles.