Windows Terminal 1.25 Fixed Its Memory Leak — Would Your Monitoring Have Caught It Before Your Users Did?

Windows Terminal 1.25.2733.0 is now stable. The changelog is short and honest: fixes for memory leaks, a fix for crashes triggered by connected Xbox controllers, a new settings search, and improved keyboard input compatibility with the Kitty protocol.

Good release. But ask yourself the uncomfortable question: how would your team have learned about that memory leak?

For most IT departments and MSPs, the answer is not "our monitoring caught it." The answer is a help desk agent complaining their jump host feels sluggish, someone remoting in on day three, opening Task Manager, and finding WindowsTerminal.exe sitting at 5.6 GB of RAM. A reboot happens. Nobody logs it. Three weeks later the same box gets weird again and the cycle repeats.

That pattern — end users acting as your de facto monitoring system — is the real story here. And it connects directly to the second item in the changelog: an Xbox controller crashing a terminal emulator is funny, but it stands for something serious. Devices and peripherals show up in your environment that no asset list, no diagram, and no dashboard knows about. This post is about closing both gaps: the processes you can't see degrading, and the devices you can't see at all.

The Problem in Depth: Thresholds, Stale Maps, and Four Tools That Don't Talk

Your RMM has thresholds, but no memory

Most RMM and monitoring platforms poll CPU and RAM every 5–15 minutes and alert on static thresholds: CPU above 90% for 15 minutes, RAM above 85%. A slow leak that grows 150 MB a day never trips anything. The process sits comfortably under the line for weeks while sessions on that terminal server get progressively worse. By the time the threshold finally fires, the machine is already sick and users have been complaining for days.

Worse, most tools alert on total system memory, not per-process. You get "MEM-01 memory above 85%" with zero indication that WindowsTerminal.exe is the culprit, that it normally holds 220 MB, and that it has roughly doubled every 24 hours since Patch Tuesday. Diagnosis then happens the old way: someone remotes in and reads Task Manager like it's 2009.

Nobody actually knows what's on the network

The Xbox controller detail scales up fast. If a controller can crash a terminal on a managed endpoint, ask what else is attached that you don't track: the IP camera facilities installed last month, the contractor's laptop on the office VLAN, the smart TV in the conference room, the label printer someone put on the network "temporarily" in March, the consumer router plugged into an access switch port in a branch office.

Most networks run on documentation that lies. The Visio diagram was last touched in 2022. The last full discovery scan ran during the Q3 maintenance window. Between scans, DHCP quietly hands out addresses to devices nobody catalogued. In practice, a mid-size network typically has 10–20% more live devices than its asset list shows — and every one of them is a blind spot precisely when you need visibility most.

And when something breaks, the tools don't correlate

Monitoring alert in one system. Ticket in a second. RMM in a third. Network discovery in a fourth. When a user says "the file server is slow," a tech correlates a CPU graph, a switch port, and a ticket history across four tabs and three logins. The MSP tech with 12 tabs across 5 tools isn't a meme — it's the daily workflow.

Two scenarios that will feel familiar:

Scenario one — the slow leak. A memory leak gradually degrades the terminal server that 30 support agents use for every customer interaction. Over a week, sessions get sluggish. Tickets arrive as "Windows is slow" and "the system is laggy" — 40+ tickets with no shared root cause visible, because the helpdesk has no monitoring data and the monitoring has no per-process trend. Friday evening, someone reboots the box. Monday, the leak starts again. Root cause surfaces the following week, because one admin happened to leave Task Manager open overnight and noticed the working set climbing. Net result: a week of degraded performance for an entire support team and 40 tickets that should have been one.

Scenario two — the device nobody installed. An unknown device — say, a misconfigured printer squatting on a static IP — appears on a user VLAN. Users report "the internet is down." Techs check the ISP, the firewall, the core switch, everything, because nobody can see that a new device appeared on port Gi1/0/23 twenty minutes before the first complaint. Three hours of MTTR for what takes five minutes to fix when you can see the topology.

The business impact compounds: first-response SLAs missed because diagnosis eats the entire clock, a restart-by-Friday culture, technicians burning out on reactive firefighting, and IT managers who can't produce an honest incident report because the monitoring data and the ticketing data live in systems that have never met.

How AlertMonitor Closes Both Gaps

Continuous discovery instead of quarterly scans

AlertMonitor continuously discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. When a new device appears, an alert fires in minutes with the details that matter: IP, MAC, vendor, switch port, VLAN. The consumer router plugged into a branch switch on a Tuesday shows up Tuesday morning, not at the next quarterly scan.

A live topology map, not a diagram of a network that used to exist

The topology map reflects the network's actual state right now. When a switch goes offline, a link drops, or a port flaps, the map shows it and the alert carries full network context: which device, which port, and what's downstream — including which users and departments are affected. Nobody opens a stale Visio file mid-outage again.

Per-process trending that catches slow leaks

Instead of relying on static thresholds, AlertMonitor baselines resource behavior per device and per process. WindowsTerminal.exe normally holding 220 MB and now climbing 150 MB a day triggers a deviation alert on day two — long before the out-of-memory event, long before the first "my session is slow" ticket. That's the difference between proactive and reactive in one sentence.

One platform: monitoring, RMM, helpdesk, and patching in the same pane

This is where the compounding happens. In AlertMonitor, the workflow looks like this:

1. The deviation alert fires on the terminal server.
2. It opens a ticket automatically, with the memory trend graph and the device's network context already attached.
3. The tech confirms the known leak, checks the installed Windows Terminal version from the same console, sees the fleet is on 1.24.x, and rolls out 1.25 through integrated patch management.
4. The ticket closes with evidence attached — and the SLA report writes itself, because monitoring, ticketing, and remediation share one data model.

Compare that to the old way: user ticket → remote in → Task Manager → guess → check the diagram → wrong switch port → ask facilities → fix discovered by accident, three-plus hours later. With unified context, it's alert → confirm → remediate → patch, frequently done before a single user notices.

Practical Steps You Can Take Today

1. Find out what's really on your network right now

Run a quick sweep and reconcile it against your asset list. Expect surprises.

# PowerShell 7+ — quick ARP-backed discovery sweep of 192.168.10.0/24
$subnet = "192.168.10"
1..254 | ForEach-Object -Parallel {
    $ip = "$using:subnet.$_"
    if (Test-Connection -ComputerName $ip -Count 1 -Quiet -TimeoutSeconds 1) { $ip }
} -ThrottleLimit 64

# Pull MAC addresses for everything that answered
Get-NetNeighbor -AddressFamily IPv4 -State Reachable |
    Where-Object IPAddress -like "$subnet.*" |
    Select-Object IPAddress, LinkLayerAddress, InterfaceAlias |
    Sort-Object IPAddress

On a Linux jump box, the same job takes two commands:

# Host discovery plus MAC lookup via the ARP table
sudo nmap -sn 192.168.10.0/24
ip neigh | grep -v FAILED

Anything in that output that isn't in your asset list is a finding. Check the vendor from the MAC OUI — it usually tells you immediately whether you're looking at a printer, a camera, or someone's game console.

2. Hunt the slow leaks you already have

Drop this on any server that "gets weird after a few days" — jump hosts, terminal servers, the box everyone shares. Run it in a dedicated session; Ctrl+C stops it. It logs the top 10 memory consumers every 5 minutes:

# Log the top 10 memory consumers every 5 minutes to expose slow leaks
$log = "C:\Logs\mem-trend.csv"
while ($true) {
    Get-Process | Sort-Object WorkingSet64 -Descending |
        Select-Object -First 10 @{n='Timestamp';e={Get-Date -Format 'yyyy-MM-dd HH:mm:ss'}},
                                @{n='Process';e={$_.ProcessName}},
                                Id,
                                @{n='WorkingSetMB';e={[math]::Round($_.WorkingSet64/1MB,1)}} |
        Export-Csv $log -Append -NoTypeInformation
    Start-Sleep -Seconds 300
}

After a day or two, see what grew:

# Which process grew the most over the collection window?
Import-Csv C:\Logs\mem-trend.csv |
    Group-Object Process |
    ForEach-Object {
        $first = [double]$_.Group[0].WorkingSetMB
        $last  = [double]$_.Group[-1].WorkingSetMB
        [pscustomobject]@{ Process = $_.Name; GrowthMB = [math]::Round($last - $first, 1) }
    } | Sort-Object GrowthMB -Descending | Select-Object -First 5

Anything trending steadily upward with no plateau is your suspect.

3. Find the version drift in the software your team actually runs

The 1.25 fixes only help if machines are actually on 1.25. Check across the fleet:

# Which Windows Terminal version is each machine running?
$targets = Get-Content C:\Scripts\workstations.txt
Invoke-Command -ComputerName $targets -ScriptBlock {
    Get-AppxPackage -Name Microsoft.WindowsTerminal | Select-Object Name, Version
} -ErrorAction SilentlyContinue |
    Select-Object PSComputerName, Name, Version |
    Export-Csv C:\Logs\terminal-versions.csv -NoTypeInformation

Import-Csv C:\Logs\terminal-versions.csv | Group-Object Version

Then update the stragglers:

winget upgrade --id Microsoft.WindowsTerminal

4. Stop doing steps 1–3 by hand

Scripts like these are solid triage tools, but they're snapshots. The network changes tomorrow, the leak restarts Monday, the next build ships on Patch Tuesday. The point of a unified platform is that discovery, per-process trending, topology, ticketing, and patching all run continuously — and alerts arrive with enough context that the 2 a.m. page becomes a 9 a.m. task.

The point was never really Windows Terminal. Your environment changes every single day — devices appear, processes drift, versions fragment — and most monitoring stacks still show you a snapshot from last quarter. Fix that, and the next memory leak gets caught on day two instead of ticket forty.

Related Resources

AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources