How to read TruGrid Sentry, SecureConnect, and Windows Connector logs

How to read TruGrid Sentry, SecureConnect, and Windows Connector logs


When troubleshooting a TruGrid session, the two most useful sources of information are the agent log on the server-side (TruGrid Sentry or SecureConnect) and the Windows Connector log on the end user's device. Knowing where they live and what to look for will resolve many issues without having to reach out to support, and will dramatically speed up the ones that do need TruGrid Customer Care.


This article walks through both logs.


Reading the TruGrid Sentry or SecureConnect Agent log


1. Where to find it


On the server where the agent is installed:

  • TruGrid Sentry: C:\Program Files\TruGrid\Sentry\Agent.log
  • TruGrid SecureConnect: C:\Program Files\TruGrid\Secure Connect\Agent.log


2. Line format


Two formats appear in the same file:

yyyy-MM-dd HH:mm:ss.ffff UTC | LEVEL | message
yyyy-MM-dd HH:mm:ss.ffffUTC|LEVEL|Component|TruGrid_Sentry_Broker_N:message


The first format is used by the main agent process for service start, Active Directory reporting, and Web Service connection. The second format is used by the broker child processes, which handle the actual RDP tunnels. The broker variant has no spaces around the pipes and includes TruGrid_Sentry_Broker_0, _1, or _2 as a prefix on the message body.


3. What a healthy session looks like


When a user successfully connects, the log produces a sequence like this:

INFO | Incoming command: <guid>; EstablishRdpConnection
INFO | SentryTunnel | ...:Attempting to create a new RDP tunnel for user:"<userGuid>"
INFO | TruGridRelayProvider | ...:Attempting to connect to TruGrid Relay via TCP:<relayIp>:443
INFO | TruGridRelayProvider | ...:A new connection has been established
INFO | TruGridRelayProvider | ...:Connection is encrypted
INFO | TruGridRelayTunnel  | ...:Connection has been established to the destination machine <hostIp>:3389 via TCP
INFO | TruGridRelayTunnel  | ...:TCP forwarding has started
WARN | TruGridRelayTunnel  | ...:UDP forwarding is not started
INFO | TruGridRelayTunnel  | ...:Connection initiated


The UDP forwarding is not started warning is logged on every tunnel and is normal.


4. Log patterns that indicate a real problem


The following events are worth recognizing and acting on. They are listed in order of how often they actually impact users.

Server timeout


ERROR | Server timeout (30000.00ms) elapsed without receiving a message from the server.


The agent stopped receiving messages from the TruGrid cloud for 30 seconds. Almost always followed by a Reconnecting to TruGrid webservice and then a Reconnected to TruGrid webservice line a few seconds later. If reconnect happens within 15 seconds, active RDP sessions usually survive.


If these are frequent (more than a few per day), the network path between the agent server and ws.trugrid.com should be reviewed. Common causes are flaky firewall connections, intermittent proxy issues, and saturated upstream bandwidth.


You can also diagnose these connectivity issues by using the Reachability Diagnostic Scripts for host and connector, respectively.


In some cases, outbound traffic might be blocked or filtered, see How to whitelist TruGrid outbound traffic on the firewall for the required outbound destinations.


Tunnel reset and recovery
WARN | TruGridRelayTunnel | ...:Forward termination. Network connection closed by remote host. Socket error:ConnectionReset. Direction:Backward. Tunnel:"<guid>"
INFO | TruGridRelayTunnel | ...:Need to reconnect. Tunnel:"<guid>"
INFO | TruGridRelayProvider | ...:A new connection has been established. Tunnel:"<guid>"
INFO | TruGridRelayTunnel | ...:TCP forwarding has started. Tunnel:"<guid>"


The same tunnel GUID appears in all four lines. This is a transient network blip on either the user's end (Direction Backward) or the agent-to-relay leg (Direction Straight), recovered automatically. The user may have noticed a brief freeze.

Isolated occurrences are normal. Investigate only when a single tunnel GUID shows three or more Need to reconnect events within five minutes, which indicates a genuinely unstable path for that user.


Failed to establish tunnel
ERROR | TruGridRelayTunnel | ...:Failed to establish tunnel. Tunnel:"<guid>" System.Net.Sockets.SocketException ... <hostIp>:3389


The agent reached the relay, but the destination Windows host did not answer on port 3389. The user clicked Connect and got nothing.

  1. Verify the target host is online.
  2. Confirm Remote Desktop is enabled on the host (Get-Service TermService should show Running).
  3. Confirm Allow Remote Desktop is permitted in the Windows firewall for Domain or Private profiles.
  4. Check network ACLs or VLAN rules between the agent server and the host.


If the same tunnel GUID has a Collect inactive tunnel line within the previous 60 seconds, this error is firing on a tunnel that was already being torn down and should be ignored. Look for a fresh tunnel GUID instead. See also How to fix RDP connection stuck at "configuring remote session" or offline machine.


Authentication failures
ERROR | Unsuccessful authentication from TruGrid to local AD for <upn>. Reason: The user name or password is incorrect
ERROR | Unsuccessful authentication from TruGrid to local AD for <upn>. Reason: The password for this account has expired
ERROR | The authentication mechanism is unknown.
  1. The user name or password is incorrect. A single occurrence followed by a Successful authentication for the same UPN within five minutes is just a typo. Three or more failures in a 60-second window with no success in between is worth investigating, either as a brute-force attempt or as a service somewhere holding a stale credential.
  2. The password for this account has expired. The user must change their password before they can log in again.
  3. The authentication mechanism is unknown. Rare. Usually indicates a stale token or client-side configuration issue. Have the user sign out of the Windows Connector completely and sign back in.


Sentry service stop and Health Monitor restart
INFO | Sentry service stopped
INFO | Sentry Health Monitor. Sentry is not running. Attempting to start it
INFO | Starting Sentry (X.Y.Z.W)


The Sentry Health Monitor is a separate Windows service that auto-restarts the Sentry agent when it stops. If the gap between stopped and the next Starting Sentry is under 30 seconds, active tunnels typically survive because brokers run as independent processes.


If the gap is longer than 30 seconds, or if you see repeated stop and start cycles, check that the TruGrid Sentry Health Monitor service is running, and review the Windows Application event log for any service-related errors around that timestamp.


5. Log noise that is safe to ignore



These appear at WARN or even ERROR level but are normal operational logging. Filter them out before searching for problems:

  1. UDP forwarding is not started. Logged on every tunnel.
  2. Forward termination. Stream was already disposed. Normal disconnect path when a user closes their session cleanly.
  3. MainBroker | ...:Maximum number of broker instances. All pipe instances are busy. Internal broker pool maintenance.
  4. Sentry Health Monitor service session changed to RemoteConnect / SessionLogon / SessionLock. Session events on the agent server itself, unrelated to end-user RDP sessions.
  5. Create or update ServiceAccount error: Access is denied. Logged at startup when the agent's service account lacks rights to manage its AD service account. Not session-impacting.


6. Quick triage by time window


When a user reports a problem, search the log for the time window of the issue. The PowerShell snippet below filters to a window and removes the four most common noise patterns:

$start = "2026-05-06 14:30"
$end   = "2026-05-06 14:45"
Get-Content "C:\Program Files\TruGrid\Sentry\Agent.log" |
  Where-Object { $_ -match "^(?<ts>\S+ \S+)" -and $matches.ts -ge $start -and $matches.ts -le $end } |
  Where-Object { $_ -match "ERROR|WARN" } |
  Where-Object { $_ -notmatch "UDP forwarding is not started|Stream was already disposed|Maximum number of broker instances|Access is denied" }


Reading the TruGrid Windows Connector log


1. Where to find it



On the end user's Windows device, in the Roaming profile of the user who runs the Connector:

  • %APPDATA%\TruGrid Connector\win_headless_logs_yyyy_MM_dd.txt


The file rolls daily. Older days remain in the same directory.


To find the most recent files from PowerShell as the affected user:

$dir = Join-Path $env:APPDATA "TruGrid Connector"
Get-ChildItem $dir -Filter "win_headless_logs_*.txt" |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 3


If the user cannot navigate the path, have them paste %APPDATA%\TruGrid Connector into File Explorer's address bar.


2. Line format
yyyy-MM-dd HH:mm:ss.ffff UTC|LEVEL|Component|MethodName|message


Note the space before UTC. This is the visible difference from the agent log format, useful when both logs end up pasted into the same ticket. All timestamps in the log are in UTC.


3. What a healthy connection looks like


INFO | LocalRdpConnection      | Checking if machine '<host>' with IP '<ip>' is on local network.
INFO | WindowsConnectorAdapter | Running relay tunnel.
INFO | ConnectorTunnel         | Attempting to create a new RDP tunnel. Tunnel:"<guid>"
INFO | TruGridRelayProvider    | Attempting to connect to TruGrid Relay via TCP:<relayIp>:443
INFO | TruGridRelayProvider    | A new connection has been established
INFO | TruGridRelayProvider    | Connection is encrypted
INFO | TruGridRelayTunnel      | Local TCP server started at 127.0.0.1:43000
INFO | WindowsConnectorAdapter | Relay connection initialization complete.
INFO | WindowsConnectorAdapter | Requested RDP session launching.
INFO | BaseRdpConnectionLauncher | RDP client started
INFO | TruGridRelayTunnel      | Connection for RDP Client has been received.
INFO | TruGridRelayTunnel      | TCP forwarding has started
WARN | TruGridRelayTunnel      | UDP forwarding is not started
INFO | TruGridRelayTunnel      | Connection initiated


The line Local TCP server started at 127.0.0.1:43000 means the Connector is listening locally for the Microsoft RDP client to attach. The RDP client started line that follows confirms the RDP client launched successfully.


4. Log patterns that indicate a real problem



The user's own internet went down

This is the most useful pattern in the Connector log because the agent-side log on the customer's server will not detect it reliably in real time:

WARN  | TruGridRelayTunnel | Forward termination. ConnectionReset. Direction:Backward. Tunnel:"<guid>"
INFO  | TruGridRelayTunnel | Need to reconnect. Tunnel:"<guid>"
ERROR | TruGridRelayTunnel | Checking internet access. Network interface is not available.
WARN  | TruGridRelayTunnel | Checking internet access. Error accessing the www.microsoft.com website.
WARN  | TruGridRelayTunnel | Checking internet access. Error accessing the www.google.com website.
WARN  | TruGridRelayTunnel | Checking internet access. Error accessing the TruGrid service.


The Connector probes three independent endpoints (microsoft.com, google.com, and the TruGrid service) on every retry. If all three fail, the user's own network connection is down. This is definitive. Nothing on the customer side or the TruGrid side is responsible.

The user needs to fix their local network: switch from Wi-Fi to wired or vice versa, restart their router, complete any captive portal sign-in, or confirm their ISP is working.


TruGrid is unreachable but general internet works


ERROR | TruGridRelayProvider | Failed to connect to TruGrid Relay via TCP. Tunnel:"<guid>"
WARN  | TruGridRelayTunnel | Checking internet access. Error accessing the TruGrid service.
INFO  | TruGridRelayTunnel | Checking internet access. Successful access to the www.microsoft.com website.
INFO  | TruGridRelayTunnel | Checking internet access. Successful access to the www.google.com website.


The user's general internet is fine, but TruGrid relay traffic is being blocked. This is almost always an outbound firewall, proxy, or content-filter rule on the user's network that does not permit traffic to *.trugrid.com or to the TruGrid relay IP range.


The user's network admin needs to permit outbound TCP 443 to TruGrid. See How to whitelist TruGrid outbound traffic on the firewall for the full list of destinations.


Certificate name mismatch warning


WARN | LocalRdpConnection | Certificate name check failed. Expected: <hostname>, Actual CN: <ssl-name>


The destination host's RDP certificate has a different CN than the host's NetBIOS name. This is normal in environments where RDP hosts use a wildcard or shared certificate, which is common with Remote Desktop Services deployments. It does not block the connection, although the user may see a one-time prompt asking them to trust the certificate.

No action is required if the connection still works. If the certificate prompt is blocking the user, importing the relevant CA certificate into the user's Trusted Root or Trusted Publishers store usually resolves it.


ObjectDisposedException during reconnect


ERROR | TruGridRelayTunnel | Failed to establish tunnel. Tunnel:"<guid>"
: System.ObjectDisposedException: Cannot access a disposed object.
ERROR | TruGridRelayTunnel | Failed to reconnect after forward termination. Tunnel:"<guid>"
: System.ObjectDisposedException: The semaphore has been disposed.


This looks alarming but is almost always logged on a tunnel that was already being cleaned up. It is an internal race condition in the cleanup path and does not represent a user-facing failure.

If it appears in isolation, ignore it. If the same tunnel GUID is also showing real errors (failed connections to relay, failed internet checks), focus on those instead.


No active tunnels - exiting


INFO | Headless Connector | No active tunnels detected, exiting application


The Connector has shut itself down because no RDP sessions are open. This is normal when the user has finished their work and closed all sessions. It is not an error.


5. Sending logs to TruGrid Customer Care


When opening a support ticket, attach:

  1. The most recent win_headless_logs_yyyy_MM_dd.txt file from the affected user, or the file from the day the issue occurred.
  2. The Agent.log from the customer-side Sentry or SecureConnect server, sliced to the time window of the issue.
  3. The user's UPN.
  4. The approximate UTC time of the failure.


A 5-minute slice on either side of the incident is usually sufficient. Attaching the full file is rarely useful and slows down the review. To slice the agent log to a specific window from PowerShell:

$start = "2026-05-06 14:30"
$end   = "2026-05-06 14:45"
Get-Content "C:\Program Files\TruGrid\Sentry\Agent.log" |
  Where-Object { $_ -match "^(?<ts>\S+ \S+)" -and $matches.ts -ge $start -and $matches.ts -le $end } |
  Out-File -FilePath "C:\temp\agent-slice.log" -Encoding utf8


Cross-referencing the two logs


When the same incident is visible in both logs, the tunnel GUID is the join key. Both the Windows Connector log on the user's PC and the agent log on the customer's server use the same GUID for the same tunnel. Searching for the GUID in both logs reconstructs the full picture: what the user's machine attempted, how the relay responded, and what the agent on the server side reported.

All timestamps in both logs are in UTC. If a user reports an issue with a local time, convert it to UTC before searching.

Please contact TruGrid Customer Care via CHAT for questions, recommendations, and for assistance.

Updated on: 08/05/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!