Binary grouping
Modern applications are often made up of several interconnected binaries—like background services or embedded components, such as browsers. This design improves performance but makes it harder to understand which processes are part of which application.
To solve this, Nexthink implements a specific way to tracks binary data in execution and connection events, using two distinct fileds:
binary
shows the application-level context for monitoring, attribution, and reporting.real_binary
shows the actual executable that ran during the event or process.
This approach applies only during runtime—it is not reflected in the table of binaries in your Nexthink instance. The link between binary
and real_binary
is calculated when each event happens.
By separating the application context from the process execution, Nexthink provides clearer, more accurate insights. This helps IT teams better track resource usage, diagnose issues, and understand network behavior within the correct application context.
Binary grouping in practice
To show how binary grouping works, this section uses Microsoft Teams as an example. This application includes multiple binaries—such as background services and shared components like WebView, its embedded browser.
When Microsoft Teams launches a helper process like msedgewebview2.exe
, the executions data shows:
binary.name = ms-teams.exe
, the main or parent binary of the applicationreal_binary.name = msedgewebview2.exe
, the binary that was actually executed
The following figures show this binary hierarchy for macOS and Windows operating systems.


NQL data model fields
Binary grouping uses the following NQL data model fields:
binary
This metric now refers to the application context responsible for the event. This is no longer necessarily the real binary that was executed.
memory
This metric represents the average memory used by all processes in the same execution tree—the main process and all sub-processes—weighted by their execution duration within the time bucket.
This value is available only for main processes and is NULL
for subprocesses.
Legacy data reports the average memory usage of the real_binary
.
real_binary
This metric identifies the actual binary executed in the process that triggered the event.
process_hierarchy
This metric indicates the runtime role of the process. Possible values:
main_process
sub_process
NULL
for legacy data.
real_memory
This metric reports the average memory used by all processes running the same real_binary
during the time bucket. The value is weighted by the execution duration of each process.
Understanding the hierarchy of processes
The system identifies a main process during runtime to determine the correct application context. This logic sets the value of the binary
field for all associated execution and connection events. The actual executable file responsible for the event is recorded in the real_binary
field.
On Windows, a process qualifies as the main process if it meets at least one of the following criteria:
The process opens a visible foreground window within 30 seconds of being launched by another process.
The binary matches a predefined list of known application executables:
The process is started by a system launcher—such as
explorer.exe
,svchost.exe
, orwininit.exe
—or no valid parent process can be identified.
Detection begins three seconds after launch and continues for up to 30 seconds to collect visibility data. If none of these conditions apply, the process is treated as its own main process.
On macOS, the system designates a responsible process—the binary accountable for user interaction and permission handling. Nexthink uses this responsible process as the main process for attribution, regardless of which subprocess generates the event.
Working with binary execution metrics
Each execution
and connection
event includes two associations:
binary
, representing the application context, such asteams.exe
real_binary
, the actual executable that was run, such asmsedgewebview2.exe
Binary-related metrics like cpu_time
, number_of_crashes
, number_of_freezes
, incoming_traffic
, or outgoing_traffic
are recorded at the real_binary
level and can be aggregated using standard functions by either binary
or real_binary
, depending on the desired scope.
Memory metrics are handled differently due to their complexity. Instead of being summed or averaged per process, memory usage is calculated as a weighted average within each time bucket. Each bucket groups all processes running the same binary, and the memory values are averaged using the execution duration of each process as the weight.
To provide both process-level and application-level visibility, two distinct fields are available:
real_memory
reflects the memory used by each process, grouped under the samereal_binary
during the time bucket. It provides a precise, process-level view of resource usage.memory
captures the total memory footprint of the entire execution tree, and is available only whenprocess_hierarchy == main_process
. It is calculated as the weighted average across all relevant processes within the same execution tree.
Interpreting data in the new model - Microsoft Teams
This section provides ready-to-use NQL queries to help you investigate execution, connection, and resource usage data for Microsoft Teams.
Last updated
Was this helpful?