High memory seen with WSS Agent

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

A customer reports an issue with version 9.6.2 and after upgrading to version 9.8.1 the issue is still there. Even though customer doesn't pass much traffic via the agent, it still consumes large amount of memory.

Tests in a lab agent yields a difference of about 70MB, while the customer reports 850MB of memory consumption.

What’s “normal” for WSS Agent memory/CPU?

Symantec does not publish a fixed “average” RAM or CPU footprint for the WSS Agent because it varies by OS, features in use (e.g., SAML login UI), and local system conditions. The official requirement is at the system level (OS + apps), not a per-process target; Windows guidance is essentially “have sufficient RAM for the OS and apps,” not a specific MB number for the agent itself. WSS Agent Technical Requirements.

What we see in the reports shared:

• The jump from ~70 MB (lab) to ~850 MB (customer) is not typical for idle/low-traffic endpoints and warrants investigation.
  
  

• In recent releases Broadcom has shipped stability/performance improvements and explicitly called out memory-leak fixes (notably on macOS; Windows builds also receive performance fixes). An upgrade to the latest generally-released agent is recommended. As of May 2025, WSS Agent 9.8.2 is available. WSS Agent Release Announcement.

Questions:

1. What is supposed to be the average memory and CPU consumption of the WSS Agent?
   
   
2. What could cause high memory usage for this customer.

Environment

WSS Agent (Windows/MAC OS)

Cause

Common contributors to higher memory on endpoints

• These are the most frequent, support-actionable causes we see in the field:1
• Authentication UI (WebView2) activity – When SAML is enabled, the agent uses Microsoft WebView2 (msedgewebview2.exe) for the login window. Stuck/looping auth, dev-tools enabled for troubleshooting, or multiple lingering WebView2 processes can inflate “agent” memory as seen in Task Manager. Troubleshooting SAML authentication in WSS Agent.
  
  

• Debug/diagnostic modes left on – Temporary troubleshooting flags (verbose logs, developer tools) increase memory and should be disabled after tests. Troubleshoot WSS Agent Issues.

• Environmental factors – Third-party endpoint security, unusual local proxy settings, or repeated reconnects to Cloud SWG (network instability) can cause extra processes/handles that raise the working set (this is the general “performance” troubleshooting area Broadcom documents). Troubleshooting WSS Agent performance issues.

Resolution

Recommendation

1. Confirm version & update if possible

   • If you’re on 9.6.2 or 9.8.1, move to 9.8.2 (latest GA) and retest memory after a reboot + sign-in cycle. Release notes and status confirm ongoing stability/performance fixes (including memory-related items in recent cycles). WSS Agent Release Announcement; Agent Release Information.

2. Collect the diagnostics (takes a few minutes)

   • Windows: use the WSS Agent diagnostics via SymDiag and the “Gather WSS Agent Diagnostics” workflow; this packages logs and key telemetry for Broadcom Support. Gather WSS Agent Diagnostics in Windows.

   • General “Troubleshoot WSS Agent Issues” page (Windows/macOS paths) is here for reference. Troubleshoot WSS Agent Issues.

   • If you can’t run SymDiag, the “Download SymDiag” article also links the wssa-diag scripts that Support accepts. Download SymDiag to detect product issues.

3. Quick local checks

   • In Task Manager / Activity Monitor, look at the process tree: wssad.exe (or WSS Agent app) plus any msedgewebview2.exe children while the login window is open. If that WebView process is the memory driver, close the SAML window, sign out/in the agent, and re-measure. Troubleshooting SAML authentication in WSS Agent.

   • Ensure any developer-tools or debug logging previously enabled for troubleshooting are turned off (the SAML troubleshooting article explains how those tools are enabled; they should be disabled after tests). Troubleshooting SAML authentication in WSS Agent.

   • Reboot once after upgrade and measure the Working Set over 10 - 15 minutes of idle time (no browsing), then during a short browsing session. If memory climbs steadily without dropping, keep the diagnostic bundle for Support (likely leak-style behavior).

4. If the footprint is still unusually high after upgrade

   • Collect and attach the WSS Agent diagnostic bundle and a brief timeline showing when memory growth occurs (idle vs. during SAML, etc.).

   • Reference the Agent Release Information item noting recent memory-related fixes so Support can compare symptom/signature against known defects. Agent Release Information.

Answering the two direct questions

Q1: “Is this normal?”

• No fixed “normal” MB value exists, and usage does vary. However, ~850 MB with little to no traffic is atypical and merits investigation with the steps above. WSS Agent.

Q2: “What is the average memory/CPU supposed to be?”

• We do not publish a per-process average. The supported baseline is that the system meets OS + application requirements and you run a current agent (latest GA). If usage seems out of proportion for your workload, follow the published performance-troubleshooting and diagnostics guidance and engage Support. WSS Agent; Troubleshooting WSS Agent performance issues.

 

Here’s a tight diagnostics checklist you should follow to get exactly what would be need to investigate further, should you require further engagement, with Technical Support.

Environment & context

• Exact WSS Agent version (e.g., 9.8.1) and platform (Windows/macOS), OS build, and RAM.
  
  

• Whether SAML/SSO is used (and if the login window is open when memory spikes).

• Any debug/verbose logging or dev-tools previously enabled (should be OFF for baseline).

Required bundles

• SymDiag → “Gather WSS Agent Diagnostics” (full WSS Agent bundle) taken:
  
  

• • Once at idle (no browsing, 10 - 15 min after sign-in).

  • Once during/after a spike (capture right when memory is high).

Point-in-time snapshots (Windows)

• Task Manager (Details) export or screenshot for:
  
  

• • wssad.exe, wssadsvc.exe, wssadtray.exe, and any msedgewebview2.exe children.

  • Include columns Working set, Commit size, CPU, Command line (add via View → Select columns).

• Command outputs:
  
  

• • tasklist /v /fi "imagename eq wssad*"

  • tasklist /v /fi "imagename eq msedgewebview2.exe"

  • PowerShell: Get-Process wssad*,msedgewebview2 | Select Name,Id,CPU,WS,PM,VM | Format-Table -Auto

Short perf trace (Windows) – 5–10 min

• PerfMon Data Collector Set with counters:
  
  

• • Process(wssad*)\Working Set, Private Bytes

  • Process(msedgewebview2)\Working Set, Private Bytes (if SAML used)

  • Memory\Available MBytes, Paging File(_Total)\% Usage
    
    

• Export the BLG (or CSV if easier).
  
  GUI (PerfMon Data Collector Set)

  1. Press Win+R → type perfmon → Enter.

  2. In the left pane: Data Collector Sets → User Defined → right-click New → Data Collector Set.

  3. Name it (e.g., WSSAgentTrace) → choose Create manually (Advanced) → Next.

  4. Create data logs: Performance counter → Next.

  5. Click Add… and add these counters:

     • Process → select instances for your agent components (e.g., wssad, wssadsvc, wssadtray) and, if SAML is used, msedgewebview2.

       • Counters: Working Set, Private Bytes.

       • Tip: If you’re unsure about instance names (e.g., wssad#1), you can select all wssad* instances shown.

     • Memory → Available MBytes

     • Paging File → instance _Total → % Usage

     • Click Add >> then OK.

  6. Set Sample interval = 5 seconds → Next.

  7. Choose a log location, e.g., C:\PerfLogs\WSSAgentTrace → Next → Finish.

  8. In User Defined, right-click your set → Start. Let it run 5–10 minutes (if you want to catch SAML/WebView2, sign out/in of the agent during this window).

  9. Right-click → Stop. The .blg file will be under the folder you picked.
     
     

  Export BLG → CSV (if Support asks for CSV):

  • Open PerfMon → Performance Monitor (graph) → Ctrl+L to load your .blg.

  • Right-click the graph → Save Data As… → CSV.

  • Or use command line:
    
    relog "C:\PerfLogs\WSSAgentTrace\WSSAgentTrace.blg" -f csv -o "C:\PerfLogs\WSSAgentTrace\WSSAgentTrace.csv" -y

macOS equivalents (if applicable)

• ps aux | egrep 'WSS|WebView'
  
  

• sample WSSAgent 10 -file sample.txt

• Activity Monitor screenshot showing WSS Agent + WebView processes (Memory tab).

Configuration notes

• Confirm no local proxy/stacking agents interfering.
  
  

• List endpoint security tools present.

• Note any frequent reconnects visible in the agent UI/logs.

Sanity actions to compare

• Reboot → sign in → measure idle 10–15 min.
  
  

• If SAML is used, sign out of agent → ensure no WebView2 child remains → sign in again → measure.

• (When feasible) test on latest GA agent build and share before/after.