Skip to content
Avanet

Diagnose Sophos Endpoint with Self Help and SDU

Random reinstallation does not resolve an Endpoint problem. First determine whether the issue affects protection components, Central communication, updates, a policy, the operating system or the network. Endpoint Self Help provides local status information and initial causes. Sophos Diagnostic Utility, or SDU, then collects the technical logs.

Before collecting logs

Document the visible symptoms before any diagnosis:

  • affected computer, operating system and time,
  • local error message or screenshot,
  • Central Health, Last Active, Agent Mode and effective policies,
  • most recent installation, update or policy change,
  • reproducible test and expected behaviour.

This information is often more useful than a very large log archive without a time reference.

Open Endpoint Self Help

In the local Sophos Endpoint interface, select About at the bottom right and then Open Endpoint Self Help Tool. The tool shows the state of important components, communication and protection services.

Self Help is useful for questions such as:

  • Is the expected component running?
  • Is a service stopped or faulty?
  • Can the agent reach Central and the update infrastructure?
  • Is there a known local configuration or permission error?

Document a red check with its name, status, detail text and time. Before repairing it, check whether a central policy or network block would recreate the cause.

If SophosDiag.exe crashes as soon as it opens and the Windows Application Event Log identifies a damaged user-specific user.config, remove only the file named in the error from the affected user profile. Do not automate deletion of the version-dependent parent directory as a fixed path. Then reopen Self Help. If the error persists, collect an SDU or repair the installed component.

Use Self Help pages selectively

The individual pages answer different questions. Do not read them as a general traffic light:

PageWhat it showsTypical next step
CommunicationMCS, Central connection, RCA, SXL or Relay reports an errorCheck Network Test, proxy, DNS and the displayed server
UpdateUpdate state, update source and last successful runCheck Update Now, cache or direct connection and AutoUpdate
PolicyLast received policy state and local overrideCompare Central assignment, communication and override
Network TestReachability of the communication paths actually configuredIsolate the failed HTTPS, DNS or ICMP step
Performance AnalysisAnalyse previously generated scanner summariesCompare high-load processes, paths and time windows

A policy update can take up to five minutes. If Override Sophos Central Policy for up to 4 hours is active locally, new Central policies are cached and applied only after the override ends. An old policy time is then not proof of a communication failure.

Under Components, compare the installed, downloaded and expected module versions. Check Not installed, differing download and installation states or multiple versions first against the update state, a pending restart and competing security software. Do not delete the local repository as a precaution. Under System, a persistent Pending Restart may originate from Windows Update. After hardware or security-software changes, rescan the software state with the Endpoint CLI before starting a repair.

Central actions normally arrive within a few seconds or minutes. Last Active, by contrast, is updated no more than approximately hourly. A user policy can take longer to change because the Central user, locally signed-in account and interactive session detected by the MCS Client must match first.

Interpret Network Test correctly

Network Test checks the Updating, Management Communication and Sophos Extensible List (SXL) channels. For each destination, the tool first attempts HTTPS, then ICMP and DNS resolution depending on the result. A successful HTTPS connection is decisive for operation. A ping or nslookup alone therefore does not prove working Central communication.

For an Update Cache or Message Relay, Self Help checks only DNS resolution of the assigned server. A green DNS test confirms neither the service state, port nor forwarding. Check the actual cache or Relay function separately.

Two limitations are particularly important:

  • After changing a cache or Relay assignment, close and reopen Endpoint Self Help; otherwise Network Test may continue to use the old destination.
  • Network Test does not support authenticated proxies and can produce misleading results.

SXL tests require administrative UAC elevation. If the device uses a Message Relay, Self Help does not run the SXL test directly because this traffic passes through the Relay.

If communication remains faulty, compare the broker addresses shown in Self Help with the local MCS configuration. Also check routing, the Windows hosts file, proxy and firewall log. After a correction, restart the Sophos MCS Client and refresh Self Help. Browser access to Central is not a substitute for this check.

Update errors without prematurely deleting the cache

A failed update within the Sophos grace period may be temporary. First check Update Now, the network, proxy, update source and time of the last successful update. Only if these checks show no cause should the local AutoUpdate cache be reset using the Sophos-documented method.

For a reproducible error, correlate SophosUpdate.log with a simultaneous packet capture and firewall or proxy logs. The decisive details are the DNS response, update server actually contacted, direct or proxied path and the first HTTP or TLS error. The most important Windows log paths are listed in Correctly evaluate Sophos Endpoint Windows logs and services.

This intervention requires Tamper Protection to be disabled and administrator rights, and it generates a Pending Restart alert. Preserve or rename the cache and repository directories; do not delete them without checking. Afterwards, a complete update must succeed and Self Help must show a healthy state again after Refresh.

Performance Analysis

From Core Agent 2024.3, Endpoint Self Help can load scanner summaries on supported Windows systems. The CSV files are stored by default under:

C:\ProgramData\Sophos\Sophos File Scanner\Logs\summary.<TIMESTAMP>.csv

They can be analysed in Endpoint Self Help on another device. The file shows which processes and paths generated scanning load during the recorded period. It does not justify a blanket exclusion. First examine the application, access pattern and narrowest technically appropriate exclusion.

When evaluating the data, compare folders with long cumulative scan times first, then frequently scanned paths and finally large data volumes. A frequently scanned path is not necessarily the path with the greatest total duration. If Self Help warns that an exclusion is too broad, use it only briefly to confirm the cause. Narrow any permanent solution to the actual subfolder or process creating the load.

Product Analysis goes further by guiding the disabling and re-enabling of protection features to isolate the component involved. It requires administrator rights and, when Tamper Protection is active, its password. Run it only on a controlled test device or in a maintenance window. Record protection and update state first, save the result, then restore every feature and update setting. The tool provides a hypothesis, not automatic approval for an exclusion.

Use File Info instead of guesswork

Under Tools > File Info, a Windows PE file can be assessed locally. Self Help shows SHA-256, size, Application Control category, product name, and resulting policy decision. Local Reputation includes Sophos data and customer Allowed Applications or Blocked Items, so it can differ from and override the live Global Reputation for the local decision.

Deep Learning requires an appropriate Intercept X licence. A green result does not prove that already detected malware is harmless; detected malware or PUA files normally cannot be dragged into this page. For a misclassification, preserve hash, signature, local and global lookup type, and the concrete policy decision, then use the documented sample-submission process.

Investigate policy, service, and operations status

If the Policy page shows stale timestamps, distinguish receipt from local processing. Check McsClient.log for connection and backoff entries and McsAgent.log for policy, namespace, and status errors. In the MCS cache, Active.policy and Latest.policy show whether a new policy arrived but did not become active locally. Restart services only after preserving the observation, then confirm the successful transition in the log.

Not every blue or empty icon on the Operations page is an error. Distinguish a disabled Data Lake function, an intentionally excluded device, or a reached daily upload limit from a genuinely faulty Live Query service. For poor Data Lake status, check SophosLiveQueryService.log, SophosOsquery.log, and service state first.

The Heartbeat section shows readiness, certificate state, and connection to a Sophos Firewall. configured, no connection currently available alone does not prove an endpoint fault, and Heartbeat status does not affect general Device Health. When a connection is expected, correlate endpoint and firewall logs by time and Device ID. Perform Registry or certificate repairs from Advanced Self Help only with export or backup, Tamper Protection disabled, and a documented rollback path.

Start SDU from the interface

Open Launch SDU from Endpoint Self Help. After selecting Start, the tool collects system information and Sophos product logs. The package can then be saved or sent to Sophos.

The archive can contain hostnames, usernames, paths, IP addresses, process lists, configurations and Events. It must not be stored in public tickets, unprotected file shares or chat histories.

An online device can also be diagnosed from Central. Open it under My Environment > Computers & Servers, then select More actions > Diagnose to start SDU collection. The archive is sent directly to Sophos. Record the displayed filename for the support case. The action and the administrator who initiated it appear in Audit Logs.

If the device is offline, Central retains the request for no more than 14 days. It then discards the request and it must be started again. The command begins with the next Central communication, so clarify timing, data-protection approval and expected device connectivity beforehand.

Product Logging and Packet Capture

Product Logging raises the log level for selected Endpoint components. Enable it only for the suspected component and a reproducible time window. After reproduction, use Revert for every change and preserve the logs with start time, end time, and test steps. Permanent debug logging can generate sensitive content and substantial data volume.

Self Help packet capture uses Windows pktmon. It is unavailable on older Windows versions and requires UAC elevation. The default limit is 512 MB; set an administrative limit to prevent a long capture filling the drive. Self Help creates ETL and PCAPNG files under C:\ProgramData\Sophos\Endpoint Self Help\PacketCapture. Closing Self Help stops the capture.

If Self Help cannot elevate logging, packet capture, or SDU, check Windows UAC settings first. Fully disabled UAC or suppressed elevation prompts can block the function. Restoring Microsoft defaults is cleaner than permanently running Sophos tools through the built-in Administrator account.

Run SDU from the Windows command line

The Windows version is normally located at:

C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe

The following command in an administrative prompt displays the built-in help:

& "C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe" -help

Important parameters include:

ParameterPurpose
-[no-]sysinfoinclude or exclude system information
-[no-]sophosinclude or exclude Sophos product logs
-outputdir="<directory>"specify the destination directory
-outputname="<path>"specify the name and path of the ZIP archive

The -help output from the locally installed version is authoritative for the available agent version. Automated collections have a storage limit, secure destination and deletion deadline.

Run SDU from the macOS command line

On a Mac, start SDU from the application bundle:

/Library/Sophos\ Anti-Virus/Tools/Sophos\ Diagnostic\ Utility.app/Contents/MacOS/Sophos\ Diagnostic\ Utility --cli --help

Use --output_path="<path>" to define the output location. The process requires the permissions needed for the data being collected. Check missing Full Disk Access or System Extension approvals separately through macOS permission diagnostics.

Understand forensic mode

SDU can create special forensic logs. This mode is intended for Sophos Incident Response or a targeted forensic investigation. It does not replace a complete enterprise forensic process and should not remain enabled without a defined mandate.

Additional rules apply to a possible compromise:

  • do not restart or clean up the device hastily,
  • document the time source and time zone,
  • write evidence only to a controlled destination,
  • record the hash, transfer and access to the archive,
  • involve those responsible for Incident Response.

Output configuration and software status by CLI

The local Endpoint CLI can output policy and software states. Output configuration shows which settings reached the device. Software Monitor reports the state of installed components and can refresh their status.

These outputs help with three common discrepancies:

  1. Central shows a policy as assigned, but the setting is missing locally.
  2. Agent Mode is correct, but a component is not installed or healthy.
  3. An update was announced, but Software Monitor remains in an error state.

Check the locally available help before use because commands and parameters can depend on the installed agent version.

Analyse logs selectively

Do not read every log in full. Start with a narrow time range and look for the first error, not merely subsequent errors. Particularly useful sources include:

  • installer and update logs for rollout problems,
  • MCS or management communication for missing Central contact,
  • Health and component logs for a red state,
  • Web, DLP, Application or Peripheral Events for policy problems,
  • operating-system Event Logs around service starts, drivers and certificates.

One error is not necessarily the cause. Timing, component and reproducible behaviour are decisive.

Prepare a support package

A good support package contains:

  1. a brief problem description and impact,
  2. the exact time with time zone,
  3. affected and unaffected comparison devices,
  4. steps to reproduce,
  5. relevant Central screenshots without secrets,
  6. the SDU archive and installer logs where applicable,
  7. measures already tested and their results.

Never attach Tamper Protection passwords, API Secrets, proxy passwords or installer tokens in plain text.

Meet the Minimum Escalation Requirements

Sophos divides the Windows Endpoint requirements for support escalations by error class. An SDU without your own analysis does not satisfy these Minimum Escalation Requirements, or MER.

For every case, first record the platform and product version, affected component, scope, frequency, reproducibility, changes before the issue and exact error messages. Logs must be complete, include the time of the error and align in time for client-server problems.

Then add scenario-specific data:

CaseAdditional minimum data
Installation or uninstallationComplete CLI, deployment method, installer log and, if required, Process Monitor capture with Advanced Output and all Events
Update or communicationSelf Help and Network Test results, update source or Relay, proxy and affected server address
Scanning or DetectionProtection feature, reproduction step, File Info reputation, relevant component log and Performance Analysis where applicable
PerformanceAffected process, CPU, RAM or I/O history, reproducible time window and corresponding ETL or process dump
Crash or blue screenComplete or active memory dump, stack analysis covering Sophos and third-party drivers, and SDU from the same period
Device ManagementEffective policy, local component, specific application or hardware and feature-specific debug log

For a performance case, first distinguish whether SophosFileScanner.exe, SEDService.exe, SSPService.exe, another Sophos process or general system load is abnormal. Globally disabled protection without a simultaneous measurement and precise component attribution does not provide a reliable cause.

A support case must include not only the collected files, but also the outcome of your own analysis: Which log shows the first relevant error, at what time, and which hypothesis did it confirm or reject?

Also check Account Preferences > Evaluation Modes for Aggressive threat detection. This Sophos Support and SophosLabs diagnostic option significantly increases system load and is not a production security baseline. If enabled, document its purpose and disable it again after the intended measurement. If the problem remains, continue as a separate performance case with a new time window.

For exploit, ransomware or HitmanPro.Alert cases, also check whether Sophos offers an Endpoint Maintenance Release containing a relevant bug fix. Create a crash dump or complete memory dump after reproducing the issue and before the SDU so that all artefacts cover the same time window. Do not rename protection DLLs or drivers without a current Sophos runbook.

Frequently asked questions

When is Endpoint Self Help sufficient, and when is SDU required?

Self Help is suitable for a quick local status check. Use SDU when logs and system information are required for deeper analysis or a support ticket.

Can an SDU archive be sent by email?

Only through an approved and sufficiently protected transfer route. The archive can contain sensitive system and user data and must be deleted according to the operational retention period after the case is complete.