TridentStack Control on Remote Desktop Session Hosts
This page explains what the TridentStack Control agent runs on a multi-session Windows server (a Remote Desktop Session Host, or any Windows server with many concurrent interactive sessions), what those processes cost per session, and how to plan capacity.
What runs on a session host
Two layers run on every Windows endpoint:
| Layer | Processes | Instances |
|---|---|---|
| Agent service and engine | TridentStack-ControlService.exe, tridentstack-core.exe | One of each per host, regardless of session count |
| Desktop UI (system tray) | TridentStack-Control.exe, plus msedgewebview2.exe helpers while a window is open | One per signed-in session |
All patching, vulnerability scanning, policy enforcement, and monitoring happen in the per-host service and engine. The per-session desktop UI only provides the tray icon, notifications, reboot prompts, and per-session features such as mapped-drive refresh. See the Agent Reference for details on the desktop UI.
The msedgewebview2.exe processes belong to the TridentStack Control desktop UI. They are Microsoft Edge WebView2 runtime helpers that render the UI window. On a busy session host they are the processes most often misattributed to a browser or to another product.
What you will see in Task Manager
Agent version 1.2.110 and later: each signed-in session runs a single TridentStack-Control.exe tray process. WebView2 helper processes are created only when a user opens the TridentStack Control window (it typically opens in one to two seconds) and exit about 40 seconds after the window is closed. An idle session host with 50 users shows 50 small native processes, not hundreds.
Versions before 1.2.110: each session runs TridentStack-Control.exe plus typically 5 to 7 msedgewebview2.exe helpers at all times, even while the window is closed. On hosts with many sessions this is visible as a large process count. Updating to 1.2.110 or later removes these idle helpers.
Per-session footprint
Measured at idle: one signed-in full-desktop session, no TridentStack Control window open, several minutes of settle time, using Windows performance counters (working set, private bytes, handle and thread counts, I/O operations per second) plus a Process Monitor kernel capture for the actual-disk-operation figures. The before column was measured on Windows Server 2022 and the after column on Windows Server 2016, with identical methodology. Sessions with real user activity and long uptimes run higher, so treat these as planning floors, not ceilings. Other multi-session environments (such as Citrix) run the same agent processes but were not separately profiled; these measurements are from native Remote Desktop full-desktop sessions.
| Per idle session | 1.2.110 and later | Before 1.2.110 |
|---|---|---|
| Processes | 1 | 6 to 8 |
| Working set | ~21 MB | ~105 MB |
| Handles | ~230 | ~2,900 |
| Threads | ~12 | ~120 |
| Task Manager I/O operations | ~4/s | ~50/s |
| Actual disk file operations | under 1/s | ~2.6/s |
The per-host service and engine add about 43 MB of working set, roughly 525 handles, and about 5 I/O operations per second, once per host.
Two notes on reading these numbers:
- Working set and private bytes answer different sizing questions on versions before 1.2.110. Summed working set (~105 MB per idle session) counts resident memory but double-counts runtime pages shared between the WebView2 helpers, while private bytes (~127 MB per idle session) counts only memory committed to those processes, including pages that are not currently resident. Use working set for RAM sizing and private bytes for commit sizing.
- WebView2 usage grows over time. On hosts where sessions stay signed in for days, per-session memory on versions before 1.2.110 grows well beyond the idle figure as WebView2 caches accumulate. On 1.2.110 and later there are no idle WebView2 processes to grow.
Why Task Manager I/O counters look high
Task Manager's I/O columns count every read and write a process issues, including named-pipe and other inter-process communication, not only disk access. The WebView2 runtime communicates between its processes over named pipes constantly, so on versions before 1.2.110 the idle I/O counters read roughly 20 times the actual disk rate (about 50 counted operations per second against under 3 real disk operations). The gap persists at a smaller scale on 1.2.110 and later, where counters still read several times the disk rate. Security and monitoring tools that track file operations also observe named-pipe traffic, which can make the desktop UI look far more disk-active than it is. The actual disk footprint at idle is in the table above.
Capacity planning
The figures below are linear projections from the single-session idle measurements above, plus the per-host service and engine, for agent 1.2.110 and later. They have not been separately validated on a host running 50 or 100 live sessions, and real hosts add overheads that do not scale linearly (profile solutions, desktop heap, other installed agents), so keep contingency margin beyond the arithmetic.
| Concurrent sessions | Processes | Working set | Handles |
|---|---|---|---|
| 10 | 12 | ~0.3 GB | ~2,800 |
| 50 | 52 | ~1.1 GB | ~12,000 |
| 100 | 102 | ~2.1 GB | ~23,500 |
Add headroom for open windows: each session that has the TridentStack Control window open adds 5 to 7 WebView2 processes and roughly 100 MB (an estimate from the measured idle WebView2 footprint; active use runs higher) while the window is open, released shortly after it closes. Reboot prompts and countdowns open the window, so a host-wide reboot prompt can add this footprint in many sessions at once; include it in maintenance-window headroom.
On versions before 1.2.110, budget ~127 MB of private bytes and ~2,900 handles per session at idle, and expect growth with session uptime. During a staged agent update, plan each host from the version that host is running.
Supported session ceiling: in-session notifications are supported for up to 128 concurrent sessions per host. Above that, additional sessions still patch and report normally, but may not receive in-session notifications.
Roaming profiles and FSLogix
When a user opens the TridentStack Control window, WebView2 creates a per-session data folder at %LOCALAPPDATA%\TridentStack Control\EBWebView. On hosts using FSLogix, User Profile Disks, or roaming profiles, %LOCALAPPDATA% typically lives inside the profile container, so this folder and its write activity land in the profile store. Factor it into profile sizing on hosts where users open the window regularly. On agent 1.2.110 and later the folder is only created when a user first opens the window.
Safe operations
Ending TridentStack-Control.exe (the desktop UI) never affects patching, monitoring, or connectivity. The UI is a separate process, and the service and engine are never children of it. Killing every UI process on a host leaves patch deployment, vulnerability scanning, and reporting fully intact.
Two things to know before you do:
- UI processes come back by design. The service relaunches the desktop UI at each logon and session reconnect, and for roughly the first 40 minutes after the service itself starts, including after every agent self-update. If you end UI processes and later see them return, that is the expected respawn behavior, not a failure of this guidance.
- What sessions lose while the UI is not running: reboot prompts and countdowns, in-session notifications (such as "scheduled for next sign-in" messages for application installs), and per-session mapped-drive refresh.
Do not stop the TridentStack-ControlService service. That is the agent itself: stopping it stops patching, monitoring, and the endpoint's connection to TridentStack Control.
Reboot prompts on multi-session hosts
A reboot applies to the whole host, so when a managed update requires a reboot and policy asks users for confirmation, the prompt appears in every active session and the first response applies to the host. Plan reboot policy on session hosts accordingly: maintenance windows or scheduled reboots are usually a better fit than interactive prompts on hosts with many users.