...
Location | Purpose |
|---|---|
| Executables and supporting libraries (read-only after install) |
| User-facing content: solutions, exchange folder, screenshots, trace logs (default) |
| Machine-scoped operational data: service state, cache (new installs)Optional location for operational data when configured for enterprise deployments |
Full layout reference: Installation Folders and Utilities Reference.
...
The runtime writes trace logs by default to C:\Users\Public\Documents\FrameworX\TraceLogs\. New installs can use C:\ProgramData\Tatsoft\FrameworX\Logs\ instead — recommended for enterprise deployments because it matches Windows conventions for operational data and is automatically scanned by most log-collection agents The location is configurable per solution via Solution Settings; enterprise deployments typically relocate it under ProgramData so it's picked up by Windows-standard log collectors (Splunk forwarder, Datadog agent, Azure Monitor, ELK).
Install logs are written to the path specified by /LOG= during silent install, or to %TEMP%\Setup Log YYYY-MM-DD.txt for interactive installs.
Windows Event Log
Service lifecycle events
Windows logs basic service ( start, stop, unexpected shutdown, license failure) are written to the Windows Application and unexpected termination events for every installed FrameworX Windows service to the System event log under source FrameworX. Use this channel for integration with Service Control Manager. SCOM, Azure Monitor, Datadog, PRTG, or any and other Windows-native monitoring tooltools pick these up automatically without any custom configuration — point your alerts at the service name (for example, TStartup-<SolutionName>).
Application-level events (solution load failures, license errors, module exceptions) are written to the runtime TraceLogs. When an Event Log entry indicates a service failed to start, the root cause detail is in the most recent TraceLog file.
Runtime System Monitor
The built-in System Monitor exposes live metrics on tags, modules, memory, and client sessions. See Runtime System Monitor Reference and Runtime Diagnostics Reference.
...
- Back up the solution folder (
C:\Users\Public\Documents\FrameworX\Solutions\) - Back up the historian database (if external)
- Stop the runtime service gracefully
- Run the installer with silent switches
- Start the service and verify via System Monitor and Event Logthe Windows System event log
6. Uninstall
Uninstall from Programs & Features or silently:
...
Symptom | First place to look |
|---|---|
Service won't start | Windows Event Log (Application System event log (source |
Port conflict |
|
License error | Event Log source |
Client can't connect to runtime | Firewall rule on runtime port, |
Web client blank / auth error | TLS certificate validity, browser console, Web Server Configuration Reference |
Database connection fails | Service account permissions, connection string, firewall rule to DB server |
...
When opening a support ticket, collect: Event Log entries (Application log, source FrameworX), the most recent TraceLog file, the install log, the output of Get-Service for the runtime service, the relevant Windows System event log entries for the service, and the solution build number.
...
- Container Deployment Reference — Docker and Kubernetes
- Linux Deployment Reference — .NET 8 on Linux servers and edge devices
- Redundancy Reference — primary/secondary runtime pairs
- SecureGateway Services Reference — multi-site communication routing
- Mobile App — mobile client deployment
11. Remote management via SolutionCenter API
From 10.1.5 GA, the recommended pattern for managing many FrameworX installations from a central place is the SolutionCenter API — a JWT-authenticated REST surface that every installation exposes on port 10108 (TWebServices). Central tools call it directly; bulk fan-out happens at the orchestration layer (Ansible, PowerShell DSC, custom dashboards) rather than per-machine WinRM or shipped agents. Surface covers solution lifecycle (list/run/stop), file ops, license activation, machine settings, and runtime connection inspection.
Activation-gated default-OFF in 10.1.5 — operators must explicitly enable per installation; see SolutionCenter API Reference for the activation procedure, scope model, endpoint catalog, and OpenAPI 3.1 document URL.
The product-install-time and service-lifecycle patterns from sections 2 and 8 above (silent installer, TManageServices.exe, SCCM / Intune / PowerShell DSC) are still the right tools for the install + service-registration layer of a fleet rollout. The SolutionCenter API operates one layer above — once installations exist, it manages what runs on them.