On this page
Troubleshooting
Locate the failing stage, then inspect its objects and logs. Record the time, object name and most recent change. Adjust one condition at a time.
| Symptom | Start here |
|---|---|
| A page does not open, or sign-in fails | Page access failures |
| A process exits, or a system service is stopped | Service startup failures |
| Devices are offline, or connections time out | Communication failures |
| Devices are online, but values are wrong or stale | Collection failures |
| Collection works, but the receiver gets no data | Forwarding failures |
| History is missing, or timestamps are wrong | History failures |
| CPU, memory, disk usage or backlog keeps growing | Resource and capacity |
Page access failures
- On the deployment host, open
http://localhost:6200. If Watchdog opens, check the TGateway status and latest error on its dashboard. If the gateway is stopped, continue with service startup failures. - On the same host, open
http://localhost:6100. If local access works but remote access fails, check the host IP, actual port, listener, firewall and reverse proxy. For containers, also inspect the port mapping. - If the page opens but sign-in fails, identify whether it belongs to TGateway, Watchdog or Studio, then check that component’s account. Their credentials are managed independently.
Use the actual address when ports have changed. After recovery, sign in locally and from the required remote browser, and confirm the expected project. See Startup and first sign-in for account and workspace checks.
Service startup failures
Start with Watchdog’s Log Viewer, Logs/Watchdog/ and the system service log. If TGateway starts and then exits, also inspect GatewayApp/Logs/XTrace/; site log configuration may specify another path. For containers, use docker logs.
| Error or symptom | Check and action |
|---|---|
A .NET runtime is missing | Run dotnet --list-runtimes and check .NET 10 Runtime and matching package architecture. |
Exec format error | Select the package matching the host architecture, such as x64 or ARM64. |
Access is denied / Permission denied | Check the reported file or device using the actual service account. On Linux, also check the executable permission. |
| A port is already in use | Check for a foreground instance running alongside the service, or another application using the port. Establish process ownership before stopping anything. |
| Watchdog works, but TGateway repeatedly exits | Check the complete GatewayApp, active project, Web port and gateway startup log. Address the first error. |
If service logs do not explain the failure, stop that service, confirm the process has exited, then start it in the foreground with the same account. See Windows foreground launch, Linux foreground launch or Docker runtime checks.
After recovery, confirm the service or container stays running, Watchdog’s startup-failure count stops increasing, and TGateway accepts sign-in. Restarting verifies a correction; it does not identify the cause by itself.
Communication failures
In Development Configuration → Collection Configuration, select the device and inspect Details, channel logs and device logs.
| Symptom | Next check |
|---|---|
| Several devices on one channel fail together | Shared connection, serial-port ownership, source service and network. |
| No response or read timeout | IP, port or serial settings, then station, protocol and whether the source receives requests. |
| Connected, but one address fails | Compare a known readable address on that device; check area, offset, type, length and protocol exception. |
| TLS handshake failure | Certificate trust, hostname, validity period and device TLS configuration. |
Continue with layered diagnosis. For connection direction, serial settings and timeouts, see Channel transport. After recovery, verify requests, responses, variable quality and new collection timestamps on the original device. A TCP connection alone is insufficient.
Collection failures
- Clear list filters, identify the correct device and variable, and check that the channel, device and variable are enabled.
- Show raw value, current value, collection time, change time, quality and error columns. Use the variable-state reference.
- If the raw value is wrong, check address, type, length and byte order with protocol debugging. If only the current value is wrong, check the read expression, scaling and decimal settings.
- If a value is constant, first check whether its collection time advances. An unchanged change time is normal for a constant source. If collection time also stops, inspect the device interval and latest error.
Compare a known value, restore the intended configuration and observe at least two consecutive sampling windows. For an initial setup, use your first collection; find complete parameters in Channels, devices and variables.
Forwarding failures
In Development Configuration → Data Forwarding, select the target and check in order:
- The group and target are enabled, and the source variable belongs to the group. A manual scope must contain saved members.
- The trigger can produce data. A constant value does not produce a new change event merely by waiting. Also check online filtering and member overrides.
- Inspect target debugging, target logs and the latest error. Check connection, authentication, Topic, target variable properties and message template.
- If the target is connected but the receiver has no data, check the full topic or physical table independently of the target’s online state.
See Run, debug and recover for scope and trigger details. For a growing backlog, inspect the outbox and distinguish pending records, retries and exhausted capacity.
After recovery, change a test value and verify its identity, new value and timestamp at the receiver. When replay is enabled, use the complete replay check for both buffered and new records.
History failures
| Symptom | Next check |
|---|---|
| Only the latest value is available | A realtime target overwrites current values. Use a history target for a sequence of samples. |
| Records exist in the database but not in the page | Selected target, variable, numeric/string category, time range and query error. |
| No records exist in the database | Group scope, trigger and target write log, followed by database permissions, table name and available disk. |
| An eight-hour timestamp difference | Target time zone, UTC suffix and database model; avoid applying the offset twice. |
| A trend has gaps or is unavailable | Collection quality and interval. Custom SQL targets do not provide the same trend view as ordinary history targets. |
Compare storage targets, then follow Data Query for queries and export. After recovery, change a test value and compare the physical record with the page result.
Resource and capacity
Use System Monitor. Record device and variable counts, intervals, scripts, forwarding and storage workloads over the same observation window.
- For sustained CPU load, identify the high-frequency device, script or forwarding task, then change one factor using capacity planning.
- For growing memory, distinguish process, managed and container measurements and inspect buffered data. A decrease after one GC does not prove a lasting correction.
- For disk growth, check log retention, history retention and offline-cache policies. Preserve active databases, WAL files and records awaiting replay.
Compare trends under the same workload and observation window after the correction. Confirm new sampling, continued delivery and the expected backlog reduction. One low-load snapshot does not establish site capacity.
Before requesting support
Collect the version, OS, architecture, reproduction steps, event time and relevant logs. Remove passwords, tokens and full connection credentials before using Support.