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 application

• real_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:

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:

  Copy

  ms-teams.exe, msteams.exe, outlook.exe, olk.exe, widgets.exe,
  widgetboard.exe, onedrive.exe, powerpnt.exe, excel.exe, onenote.exe,
  winword.exe, msedge.exe, pad.console.host.exe, searchapp.exe,
  pbidesktop.exe, bingwallpaper.exe, zoom.exe, acrobat.exe,
  firefox.exe, chrome.exe

• 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 as teams.exe

• real_binary, the actual executable that was run, such as msedgewebview2.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 same real_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 when process_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.

devices
| include execution.crashes during past 24h
| where binary.name in ["ms-teams.exe", "msteams"]
| compute number_of_crashes_ = crash.number_of_crashes.sum()
| include execution.events during past 24h
| where binary.name in ["ms-teams.exe", "msteams"]
| compute number_of_freezes_ = number_of_freezes.sum()
| where number_of_crashes_ > 0 or number_of_freezes_ > 0
| list device.name, number_of_crashes_, number_of_freezes_

Which binary is responsible for Microsoft Teams freezing?

This query shows which real binaries used by Microsoft Teams reported freezes in the past 7 days. It summarizes the total number of freezes per real_binary and version, helping you identify which components, such as subprocesses, contribute to application instability.

Copy

execution.events during past 7d
| where binary.name in ["ms-teams.exe", "msteams"]
| summarize number_of_freezes_ = number_of_freezes.sum() by binary.name, real_binary.name, real_binary.version
| where number_of_freezes_ > 0
| list binary.name, real_binary.name, real_binary.version, number_of_freezes_
| sort real_binary.name asc

The query returns the following table:

execution.events during past 7d
| where real_binary.name in ["msedgewebview2.exe"]
| summarize number_of_freezes_ = number_of_freezes.sum() by binary.name, real_binary.name
| list binary.name, real_binary.name, number_of_freezes_
| sort number_of_freezes_ desc

devices
| include connection.events during past 7d
| where binary.name in ["ms-teams.exe", "msteams"]
| compute incomming_traffic_ = incoming_traffic.sum(), outgoing_traffic_ = outgoing_traffic.sum()
| list device.name, incomming_traffic_, outgoing_traffic_
| sort outgoing_traffic_ desc

What are the NQL query limitations for with and include ?

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 as msedgewebview2.exe

When joining the binaries table with event tables, such as execution.events or connection.events, NQL uses the binary association only. NQL supports a single join path between two tables, and that path is based on the binary field—not real_binary.

See the following examples for explanations using real-life scenarios.

Example 1

Syntactically valid query, resulting in misleading results:

Copy

binaries 
| with execution.events during past 1h
| where real_binary.name == "msedgewebview2.exe" 
| compute cpu_time_ = cpu_time.sum() 

The query returns the following table:

While the syntax is valid, the results may be misleading:

1. The where clause filters for events where the real_binary is msedgewebview2.exe.

2. However, the joint between binaries and execution.events is still made using the binary association.

3. As a result, the computed cpu_time_ reflects only the resource usage from msedgewebview2.exe, but it is grouped under the parent binary, such as teams.exe, outlook.exe, which can be confusing.

Using this type of partial attribution in dashboards or reports can lead to incorrect conclusions. When filtering on real_binary, avoid aggregating or displaying results using the binary association unless you intend to summarize real_binary activity under the parent context.

Example 2

Syntactically invalid query :

Copy

binaries
| with execution.events during past 1h
| where real_binary.name == "msedgewebview2.exe"
| compute cpu_time_ = cpu_time.sum()
| list binary.name, real_binary.name, cpu_time_

In NQL, when joining from the binaries collection to execution.events, the query uses the binary association defined in the data model. This means that binaries can access only the execution.events that reference it through the binary field.

The real_binary association is not available in this joint context. Because binaries is linked only through the binary field in execution.events, trying to access real_binary.name results in an error, because it is not available in the query context.