zenon 11 Smart Client: Troubleshooting Add-In Scripts

On a zenon 11.00 Smart Client, Add-In package files can exist in the local AddInStore while the Add-In Framework fails to initialize and exposes no Add-Ins in Manage Service Engine Services. File presence alone therefore does not verify successful package retrieval, context initialization, or framework startup.

Identify the failure state

The affected Windows 11 computer had the Runtime files under C:\...\RT\FILES\zenon\system\AddInStore, but its Add-Ins did not appear in Manage Service Engine Services. Another Windows 11 computer connected to the same server displayed and ran the same scripts. This comparison narrows the investigation to a client-specific condition, although the evidence does not identify the exact dependency or configuration difference.

Interpret the Diagnostics Viewer errors

The logs show a failure chain inside the Add-In Framework rather than evidence of a missing script file: installed framework packages cannot be retrieved, the Add-In context cannot initialize, and the framework cannot start. A separate message states that framework debugging cannot be enabled. The evidence does not establish whether that debugging error is causal or secondary.

Cannot enable debugging.
Cannot initialize Add-In .NET Extension for instance id '...'.
Retrieving Add-Ins of instance id '...' failed.
Cannot startup Add-In .NET Extension for instance id '...'.

The most frequently referenced components were PackageInstaller.cpp, AddInInitializer.cpp, and AddInManager.cpp. These names help classify the failure stage, but they do not reveal a confirmed root cause.

Exclude changes that did not resolve the issue

Several attempted changes produced no recovery: copying zenon6.ini from the working computer, copying Service Engine files, installing the .NET Core Hosting Bundle 3.1.32, enabling IIS Windows Authentication, and turning off the tested Windows Defender Firewall protections. Do not repeat these actions as an assumed fix unless a log or machine comparison identifies the corresponding dependency.

The computers used different processor vendors, but no evidence connects Intel or Ryzen processors to the failure. Likewise, the presence of .NET 3.5 and 4.8 on both machines does not prove that every Add-In Framework prerequisite or package is healthy.

Collect evidence and escalate the unresolved failure

1. Reproduce the failure and capture the complete Diagnostics Viewer log, including timestamps, instance identifiers, and unredacted local paths where organizational policy permits.
2. Compare the working and affected clients for machine-specific differences, focusing on the point where installed Add-In Framework package retrieval fails.
3. Check whether the behavior occurs on additional Smart Client computers. A failure isolated to one computer supports a client-specific investigation; failures across several clients change the scope.
4. Have the local product support team review the complete logs. The available evidence contains no confirmed repair, and detailed log analysis was the recommended next action.

Verify recovery by confirming that the Add-Ins appear in Manage Service Engine Services, start successfully, and no longer generate package-retrieval, context-initialization, or framework-startup errors.

FAQ