Troubleshooting

DataTalk does not run in a virtual machine (CPU without AVX)

Symptom: DataTalk Manager is installed in a virtual machine (Proxmox, KVM, VMware, Hyper-V…). The installation finishes, but DataTalk does not run.

Root cause: DataTalk requires a CPU with the AVX instruction set. A physical server almost always has it, but a hypervisor passes only some CPU features to the VM. The default CPU types in Proxmox (kvm64, x86-64-v2-AES) do not pass AVX, so DataTalk cannot run. This applies to both Linux and Windows installations: WSL2 inside a Windows VM gets the same CPU features as the Windows VM.

Fix on Proxmox — set the CPU type to host

1. Select the VM → Hardware → Processors → Edit

2. Set Type to host → OK

   Or run on the Proxmox host:

   qm set <VMID> --cpu host

3. Fully stop and start the VM. Restarting the guest OS is not enough — QEMU must restart with the new CPU type:

   qm stop <VMID>
   qm start <VMID>

With host, the VM gets all features of the physical CPU, including AVX.

Other hypervisors

• VMware ESXi / vSphere — if the cluster uses EVC, choose an EVC mode that includes AVX (Intel Sandy Bridge or newer, AMD Bulldozer or newer)
• Microsoft Hyper-V — turn off processor compatibility mode for the VM (VM settings → Processor → Compatibility), which hides newer CPU features
• Physical host CPU — the CPU of the physical server must support AVX itself (Intel Sandy Bridge / AMD Bulldozer or newer)

Verify inside the VM

Linux:

grep -o -w avx /proc/cpuinfo | sort -u

Expected output: avx. Empty output means the VM does not see AVX.

Windows: run Coreinfo from Microsoft Sysinternals with coreinfo64 -f and check that the AVX line is marked with *.

After the fix, restart DataTalk Manager or reboot the VM.

---

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.

---

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)

1. Open Windows Security → Firewall & network protection
2. Select the active network profile (Domain / Private / Public)
3. 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:

1. Open Services (services.msc)
2. Find the service named DataTalk
3. Right-click → Start
4. 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

1. Stop the conflicting service and restart DataTalk Manager
2. 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)

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 myscadasrv to 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.

1. Stop the service if it is currently running:

   net stop DataTalk

2. Set a new password for the Windows account — note it down, you will need it in the next step:

   net user myscadasrv YourNewPassword!

3. 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

4. Re-add myscadasrv to the Administrators group if it was removed by domain policy:

   net localgroup Administrators myscadasrv /add

5. Start the service:

   net start DataTalk

Permanent fix — GPO exceptions for the myscadasrv account

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).

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

Once both exceptions are in place, the myscadasrv account will retain its password and its Administrator membership regardless of domain policy refreshes.