Troubleshooting
Fixes for common DataTalk Manager issues — service account expiry, OPC UA connectivity, WSL2 errors, port conflicts, and Windows domain policy (GPO) disruptions.
On this page
DataTalk Manager stops working after a few months
Symptom: DataTalk Manager worked fine after installation but stopped unexpectedly after 1–3 months — without any updates or intentional changes.
Root cause: During installation, DataTalk Manager creates a Windows service account named myscadasrv. This account is configured to never expire. However, on corporate-managed Windows machines, domain Group Policies (GPO) often override local user settings and force a password expiry after 30–90 days. Once the password expires, the myscadasrv service can no longer log in and the system stops.
1. Verify whether you are affected
Open PowerShell as Administrator and run:
net user myscadasrv
In the output, look at these two lines:
Password expires Never ← OK if "Never"
Account expires Never ← OK if "Never"
If either shows a specific date instead of Never, you are affected.
2. Fix — set password to never expire
WMIC --% USERACCOUNT WHERE Name="myscadasrv" SET PasswordExpires=FALSE
3. Fix — set account to never expire
net user myscadasrv /expires:never
4. Verify the fix
Run net user myscadasrv again and confirm the output now shows:
Password expires Never
Account expires Never
Then restart the DataTalk service or reboot the machine.
If your IT department manages password policies via Active Directory, ask them to create an exception for the myscadasrv service account, or move the machine’s OU to one without a forced password expiry policy.
PLC communication fails — OPC UA
Symptom: DataTalk Manager cannot communicate with a PLC over OPC UA. The connection times out or is refused immediately.
Root cause: Windows Firewall is blocking the OPC UA port (default 4840/TCP).
Quick fix — disable Windows Firewall (lab / isolated network only)
Only disable the firewall on machines that are not directly exposed to the internet or an untrusted network.
- Open Windows Security → Firewall & network protection
- Select the active network profile (Domain / Private / Public)
- Toggle Microsoft Defender Firewall to Off
Recommended fix — add a firewall exception
Instead of disabling the firewall entirely, add an inbound rule for OPC UA:
New-NetFirewallRule `
-DisplayName "OPC UA (DataTalk)" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 4840 `
-Action Allow
If your PLC uses a non-standard OPC UA port, replace 4840 with the correct port number.
Verify connectivity
After adding the rule, test the connection from the DataTalk Manager machine:
Test-NetConnection -ComputerName <PLC_IP> -Port 4840
Expected output: TcpTestSucceeded : True
WSL2 fails to start — error 0x800705b4
Symptom: After installation (or after moving to a VM), DataTalk Manager cannot start. The WSL log shows error 0x800705b4 or the service appears to hang during startup.
Root cause: DataTalk Manager uses WSL2 internally. When Windows runs inside a virtual machine, nested virtualization must be enabled on the hypervisor host — otherwise WSL2 cannot create its own VM.
See the full setup guide: Running on a Virtual Machine — WSL2 Nested Virtualization
DataTalk service does not start after Windows Update
Symptom: After a Windows Update or restart, DataTalk Manager shows as stopped in the Manager UI or in Windows Services.
Steps to recover:
- Open Services (
services.msc) - Find the service named DataTalk
- Right-click → Start
- If the service fails to start, check the Windows Event Viewer under Windows Logs → Application for an error from source
DataTalk
Common causes and fixes:
| Event log message | Likely cause | Fix |
|---|---|---|
Logon failure | Service account password expired (GPO override) | See Password expiry fix above |
WSL failed to start | Nested virtualization not enabled, or WSL outdated | Run wsl —update in PowerShell; or see the VM guide |
Port already in use | Another service occupies port 80 or 443 | Change DataTalk Manager ports in Settings, or stop the conflicting service |
Access denied | WSL distro registered under a different user account | Re-import the distro under the myscadasrv service account |
Port conflict — web server will not start
Symptom: DataTalk Manager installs successfully but the web interface is unreachable. The Manager UI shows the runtime as stopped with a port error.
Cause: Another application (IIS, Apache, Skype, Teams, or another DataTalk Manager instance) is using port 80 or 443.
Find the conflicting process
netstat -ano | findstr ":80 "
netstat -ano | findstr ":443 "
Note the PID in the last column, then identify it:
Get-Process -Id <PID>
Resolution options
- Stop the conflicting service and restart DataTalk Manager
- Change DataTalk Manager ports — open the Manager UI, go to Settings, and change the HTTP/HTTPS ports to unused ones (e.g., 8080 / 8443)
Service account disrupted by Windows domain policy (GPO)
This is one of the most common causes of DataTalk Manager failures in larger organizations. If your machine is joined to a Windows domain, read this section carefully — the symptoms are easy to misread as a software bug. Contact your IT department before reinstalling DataTalk Manager.
Affected environments: Corporate networks where the Windows machine is joined to an Active Directory domain managed by an IT department.
During installation, DataTalk Manager creates a local Windows service account named myscadasrv. This account is granted Administrator privileges and configured with a static password — both are required for WSL2 to start and for the service to run correctly.
In domain-managed environments, Group Policy Objects (GPO) applied by the domain can silently override these local settings, causing the service to stop working. Two policies are responsible:
| Policy | What it does | Effect on DataTalk |
|---|---|---|
| Password expiry policy | Forces all accounts to change their password every 30–90 days, even if the local account is set to “never expire” | The service can no longer log in — Logon failure in the Event Log |
| Restricted Groups / Privileged Access policy | Periodically resets the membership of the local Administrators group to a domain-defined list, removing any locally added accounts | WSL2 cannot start — Access denied when launching the service |
Symptoms
- DataTalk Manager stops working spontaneously — no updates, no manual changes
- Manually resetting the password or re-adding
myscadasrvto Administrators fixes it temporarily, but the problem recurs after the next GPO refresh (typically within hours or after the next restart) - The Windows machine is managed by an IT department via Active Directory
Short-term fix (temporary)
The DataTalk service stores the myscadasrv password in two places that must always match:
- Windows user account — the actual account password set in Windows
- Service Log On configuration — the password the service uses to start under that account
Changing only one of them will cause an Access Denied error when the service tries to start. Follow all steps before starting the service.
-
Stop the service if it is currently running:
net stop DataTalk -
Set a new password for the Windows account — note it down, you will need it in the next step:
net user myscadasrv YourNewPassword! -
Update the same password in the service Log On configuration:
- Press Win + R, type
services.msc, press Enter - Find the service named DataTalk
- Right-click → Properties → Log On tab
- Enter the new password in both the Password and Confirm password fields → OK
- Press Win + R, type
-
Re-add
myscadasrvto the Administrators group if it was removed by domain policy:net localgroup Administrators myscadasrv /add -
Start the service:
net start DataTalk
This fix will stop working the next time domain policy is reapplied (GPO refreshes automatically, typically every 90 minutes or on restart). Contact your IT department for a permanent solution.
Permanent fix — GPO exceptions for the myscadasrv account
Forward this section to your IT administrator. The two exceptions below are standard Active Directory operations. No changes to the DataTalk Manager installation or service configuration are required — only domain policy adjustments on the IT side.
The simplest permanent solution is to leave the myscadasrv local account in place and ask your IT department to configure two policy exceptions. No reinstallation or migration is required.
Exception 1 — Exempt myscadasrv from the domain password expiry policy
Active Directory supports Fine-Grained Password Policies (FGPP), which allow different password rules for specific accounts. Ask IT to create a FGPP that sets password expiry to Never for the myscadasrv account (or for a dedicated PSO — Password Settings Object — applied to service accounts).
FGPP is available on all Active Directory environments running Windows Server 2008 or later. Your IT administrator can configure it in Active Directory Administrative Center → your domain → System → Password Settings Container.
Exception 2 — Protect the Administrators group membership using GPO Preferences
If IT uses a Restricted Groups policy, it periodically overwrites the local Administrators group and removes myscadasrv. The fix is to replace Restricted Groups with a GPO Preference (Group Policy → Preferences → Local Users and Groups), configured with action Update instead of Replace. This adds myscadasrv to Administrators without removing other members.
Ask IT to add the following entry to the GPO Preference applied to this machine:
| Setting | Value |
|---|---|
| Action | Update |
| Group name | Administrators (built-in) |
| Member to add | myscadasrv |
Using Update instead of Replace is the key difference — it adds the member persistently without overwriting the entire group on each GPO refresh.
Once both exceptions are in place, the myscadasrv account will retain its password and its Administrator membership regardless of domain policy refreshes.