# 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.

Microsoft Teams in Application Monitor (macOS)

Microsoft Teams in Task Manager (Windows)

**NQL data model fields** Binary grouping uses the following NQL data model fields:

Field name	Description
`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.

{% hint style="info" %} To ensure consistent analysis, Nexthink recommends using `binary` for high-level monitoring and attribution, and `real_binary` and `real_memory` for granular investigations at the process level. {% endhint %} **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: ``` 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`, or`wininit.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.

Which devices crash and freeze while running Microsoft Teams?

This query returns the number of crashes associated with Microsoft Teams for both Windows and macOS, based on the application context (`binary`). You can either use it in a dashboard or to define a custom trend. See the [Custom trends management](https://docs.nexthink.com/platform/user-guide/administration/content-management/custom-trends-management) documentation. ```sql 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. ```sql 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:

What applications are affected when msedgewebview2.exe freezes?

This query identifies which applications (`binary`) are launching `msedgewebview2.exe` and how many freezes that subprocess generated over the past 7 days. It helps you trace freeze events back to their parent applications using improved binary grouping. ```sql 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 ```

What is the incoming and outgoing traffic generated by Microsoft Teams on each device?

This query lists devices with Microsoft Teams traffic over the past 7 days. It shows the total incoming and outgoing network traffic per device, helping you identify which endpoints are generating the highest data usage for Teams. ```sql 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 as`teams.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: ```sql 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 :

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.