FxResourceMonitor Reference

Record the CPU and memory of a FrameworX server and of every runtime process to a log file, to investigate high CPU, memory growth and crashes.

Reference → Troubleshooting → FxResourceMonitor

Overview

FxResourceMonitor is a command-line tool installed with FrameworX. At a fixed interval it records the CPU and memory of the machine and of each FrameworX runtime process: TServer, TRichClient and every TRunModule. Each module and each device channel is identified separately. It also records when runtime processes start and end, with their exit code, so crashes and restarts appear in the log.

Use it to find which process uses the resources, when, and whether usage keeps growing over hours or days. Growth in memory, handles, threads or GDI objects is the usual sign of a leak.

• It never connects to the runtime. It keeps logging while the runtime is slow, hung or restarting, and it does not affect the runtime.
• It is light. Each sample takes about 10 ms of CPU, and the tool uses a few tens of MB of memory. It logs its own CPU and memory on every sample.
• CPU and memory values use the same scale as Windows Task Manager.

The tool has no user interface. You start it from a command prompt.

Requirements and Location

The default install folder is C:\Program Files\Tatsoft\FrameworX\fx-10\. Both builds monitor both kinds of runtime: .NET Framework 4.8 processes (TServer.exe, TRunModule.exe, TRichClient.exe) and Multiplatform processes started as dotnet TServer.dll or dotnet TRunModule.dll.

Run it from an Administrator command prompt when the runtime runs as a Windows service or under another user account. Without Administrator rights, processes of other accounts are still listed with CPU, memory, threads and handles, but not with their command line, exit code, I/O or memory detail. A .NET 10 process started as dotnet by another account cannot be identified at all, and a NOTE line names it. The log header shows whether the tool ran as Administrator.

You can copy FxResourceMonitor.exe alone to a machine with an older FrameworX version. It then writes its logs to a FxResMonLogs folder next to itself.

Start and Stop

FxResourceMonitor.exe [options]

All options are optional. Write them as /key:value, -key value or --key=value. Run FxResourceMonitor.exe /help for the full list.

To stop the tool, press Ctrl+C, close the window, or let /duration end the run. The tool then writes a STOP line and closes the file. Every sample is written to disk immediately, so a forced stop loses at most the sample in progress.

The tool does not restart after a reboot unless you register it with /install. See Start at Every Boot below.

Options

With the defaults, the log files use at most about 2 GB of disk (100 files of 20 MB).

Where the Logs Are Written

By default the tool writes to the FrameworX TraceLogs folder, next to the runtime's own trace files: C:\Users\Public\Documents\FrameworX\TraceLogs\. With /out, it writes only to the folder you give.

The tool writes to a FxResMonLogs folder next to itself, and says why on the console, when the FrameworX files it uses to find TraceLogs are not next to it, or when the TraceLogs folder is not writable. As a last resort it uses the system temp folder.

A runtime configured to write its traces to ProgramData writes them to ProgramData\...\Logs. The monitor still writes to TraceLogs unless you give /out.

File name: FxResMon_<MACHINE>_<yyyyMMdd_HHmmss>_<process id>_<part>.log, for example FxResMon_SERVER01_20260924_155903_15896_001.log. A new part (_002, _003) starts when the file reaches /maxmb. Every part repeats the header and the list of processes, so each file can be read on its own. Files are never overwritten.

What the Log Contains

The log is UTF-8 text with one record per line. Fields are separated by ; and use a decimal point. Lines starting with # are the header, which includes a # FIELDS line describing every record type. You can open the file in Excel, process it with a script, or give it to an AI assistant.

The header records the tool version and build, the FrameworX version and log folder, the start time and time zone, the machine, user and Administrator status, the operating system, the .NET version, the CPU model, cores and caches, installed and free memory, boot time and uptime, free space on the log disk, and the settings used.

The tag identifies a process over time, even when it restarts with another process id. For TRunModule it is the module and device channel, for example Alarm, Dataset or Device/Modbus1. For TServer it is <solution>:<port>, for example MySolution:3101.

An empty field means the value is not readable with the current permissions, or is a rate on the first sample of a process.

Reading the Values

• CPU % is the share of the whole machine over the interval, the scale Task Manager uses. Task Manager truncates it to an integer, so 2.76 shows as 2. One fully busy core equals 100 divided by the number of logical processors, for example 10 % on a 10-processor machine.
• Memory. The KB value equals the Task Manager Memory column. Private MB rising steadily over hours is the classic memory-leak signal. .NET processes go up and down as garbage collection runs, so watch whether the lowest values keep rising. Virtual MB matters only for 32-bit (x86) processes.
• Handles, threads, GDI and USER objects that keep growing are also leak signals. GDI and USER objects apply to processes with a user interface, such as TRichClient.
• Context switches per second show how often a process's threads are scheduled. A mostly idle process with thousands per second and a high kernel CPU share wakes up too often, from short sleeps, timers or polling.
• Wait reason on THREAD lines: DelayExecution is Thread.Sleep, UserRequest is a wait on an event or lock, WrQueue is the thread pool or I/O completion. Use the thread id to find the thread in a dump or debugger.
• TCP connections that keep growing indicate a socket leak.
• Exit codes: 0xC0000005 access violation, 0xE0434352 unhandled .NET exception, 0xC00000FD stack overflow, 0xC0000409 fail-fast or buffer overrun, 0x80131506 .NET runtime fatal error. 1 or -1 usually means the process ended normally or was killed.

A short run shows the load. Detecting a leak needs hours or days of normal use.

Memory Dumps

Dumps are off by default. With /dump, a process that meets a trigger for several consecutive samples gets one dump attempt. The dump includes the heap, which is enough for .NET memory and thread analysis.

• The first 5 minutes of a process do not count toward a trigger, because start-up is busy.
• The process is paused while the dump is written, from under a second to several seconds. A dump takes about the process's private memory on disk. The tool skips the dump, with a NOTE, when less than 1.5 times the private memory plus 512 MB is free.
• A NOTE is written before the dump and a DUMP record after it. With /dump, a NOTE at start says whether the dump folder is ready.
• Dumps contain process memory, which can include customer data, connection strings and credentials. Each dump file is readable only by SYSTEM, Administrators and the account running the monitor, even when the log folder is open to everyone. The tool refuses to write a dump through a junction or link in the folder path.
• Run the tool as Administrator to dump a runtime that runs as a service. Log retention (/maxfiles) never counts or deletes dumps.

Log Analysis

FxResourceMonitor.exe /analyze
FxResourceMonitor.exe /analyze:D:\FxLogs

/analyze reads the logs of the default log folder, or of the folder or file you give, prints a report and saves it as FxResMon_Analysis_<stamp>.txt next to the logs. Logs from several machines in one folder are reported per machine.

The report has one block per process instance, identified by process id and start time, so two clients of the same solution are never merged. Each block shows CPU % average, 95th percentile and maximum, also as a percentage of one core, context switches, and for private memory, handles, threads, GDI and USER objects the lowest value of each 10-minute window with its trend per hour. The first 30 minutes of each process are left out of the trends, because start-up growth is not a leak.

The report also lists the dumps written. Short process instances without a finding, such as a module that restarts, are summarized in one line per program.

Start at Every Boot

FxResourceMonitor.exe /install [options]
FxResourceMonitor.exe /uninstall

Run these from an Administrator command prompt. /install creates the scheduled task FxResourceMonitor, which runs as SYSTEM at system startup with the other options you give, and starts it immediately. Running /install again replaces the options and restarts the monitor. /uninstall removes the task. Stopping the task ends the monitor without a STOP line.

Run /install from the FrameworX installation folder. Because the task runs the program as SYSTEM, /install refuses with exit code 7 when the program, its FrameworX DLLs, the .NET runtime it uses, or any folder above them can be changed by an account other than SYSTEM, Administrators or TrustedInstaller.

Disk Space

Each sample writes about 150 bytes for the machine and about 190 bytes per monitored process. At the default 10-second interval:

Halving the interval doubles these numbers. THREAD lines add volume only while a process is hot. If the disk fills up, the tool drops samples, retries at most once a minute and continues in a new file when space is available, without deleting older logs.

Examples

Exit Codes

Limitations

• A process that starts and ends between two samples does not appear in the log.
• The tool shows which process uses resources and when, not which part of the code. Once you find a suspect process, take a memory dump or a trace of that process.
• The log contains the machine name, user name and full command lines, including solution file paths and ports. Review it before you send it outside your organization.

In this section...