Evidence of Execution: SRUM Forensics

 

In contemporary high-profile investigations, digital evidence frequently constitutes the cornerstone of prosecutorial narratives, underscoring its probative value in establishing criminal culpability. Consequently, digital forensic examiners routinely encounter sophisticated counter-forensic techniques designed to obliterate traces of illicit activity. Among the resilient evidentiary artifacts that persist despite such efforts is the System Resource Usage Monitor (SRUM), a Windows-native telemetry repository that continues to chronicle user and application behavior long after the execution or removal of counter-forensic tools.

For instance, during the analysis of a suspected corporate network breach involving data exfiltration, forensic examination of SRUM records can enable analysts to identify applications executing on compromised hosts that systematically transferred sensitive information to external competitors or nation-state actors. SRUM’s Application Resource Usage and Network Usage tables provide granular attribution by correlating process execution, resource consumption, and network telemetry on an hourly basis, often revealing covert command-and-control or exfiltration activity that evades conventional logging mechanisms.

SRUM data proves equally indispensable in insider threat investigations. Consider the scenario of an employee surreptitiously transferring substantial volumes of proprietary data from the corporate environment to a personal laptop prior to leaving the company. Forensic review of the SRUM database would typically document elevated network receive activity associated with explorer.exe (or similar processes) under the subject user’s Security Identifier (SID). Subsequent analysis could further corroborate the employee’s connection to an external wireless network—such as a public access point at a coffee shop—by recording connection metadata including SSID, interface details, connection duration, timestamps, and the volume of bytes transmitted and received by applications (e.g., web browsers or synchronization clients accessing Dropbox or equivalent cloud storage). This facilitates precise temporal reconstruction and geolocation inference of the data movement.

In one documented forensic engagement involving a seized workstation that remained powered on post-acquisition, examiners leveraged SRUM artifacts to decisively rebut defense assertions of post-seizure tampering. The defense expert alleged that investigative personnel had authenticated to the system using the suspect’s credentials and planted inculpatory evidence. However, SRUM’s comprehensive logging of system uptime, application launches, associated user SIDs, and execution contexts demonstrated that no interactive logons or user-initiated processes had occurred following lawful seizure. This evidentiary timeline provided irrefutable corroboration that the system had not been tampered with by unauthorized actors, thereby validating the integrity of the acquired digital evidence.

SRUM’s evidentiary strength lies in its aggregation of persistent, tamper-resistant records within the SRUDB.dat database, making it an essential component of modern Windows forensic toolkits when traditional artifacts have been compromised or deleted. When properly parsed and contextualized with corroborative sources (e.g., Prefetch, ShimCache, and event logs), SRUM significantly enhances attribution, timeline reconstruction, and counter-forensic resistance in both criminal and civil matters.

The System Resource Usage Monitor (SRUM) operates as a core component of the Windows Diagnostic Policy Service (DPS), systematically tracking a broad spectrum of system performance metrics, application execution, and resource utilization. Native to Windows 8 and all subsequent versions—including Enterprise editions—SRUM is enabled by default upon system initialization and maintains persistent telemetry independent of user-visible configurations.

Before 2015, SRUM remained largely unrecognized within the broader digital forensics community. Its forensic significance was formally introduced in February 2015 through the seminal research paper “Forensic Implications of System Resource Usage Monitor (SRUM) Data in Windows 8” authored by Yogesh Khatri, Assistant Professor at Champlain College. The paper was presented at the SANS 2015 DFIR Summit, followed by a detailed interview with Khatri on the CyberSpeak podcast in August 2015, which significantly elevated awareness of SRUM’s evidentiary value among practitioners.

End users may observe a limited subset of SRUM data through the Task Manager interface, specifically under the App history and Details tabs. The Task Manager aggregates selected records from the underlying SRUM database (SRUDB.dat), presenting both real-time performance statistics and approximately 30 days of historical usage information within the App history view.

Notably, while the App history tab includes a “Delete usage history” option, empirical forensic testing demonstrates that this function does not immediately purge records from the SRUM database. This residual persistence further enhances SRUM’s utility as a counter-forensic-resistant artifact, as user-initiated cleanup attempts frequently prove incomplete or delayed in their effect on the underlying telemetry.

The SRUM database constitutes a rich repository of forensic artifacts, yielding critical telemetry that frequently proves indispensable during digital investigations. Among its most probative elements are detailed records of wireless and wired network affiliations (including SSID and interface metadata), hourly application execution timelines, and the specific user Security Identifier (SID) associated with each process launch. Additional high-value data points include granular network utilization metrics—bytes sent and received per application within each hourly aggregation interval—along with disk I/O activity (read/write volumes) and power state indicators (AC power versus battery operation).

This multifaceted dataset enables forensic examiners to reconstruct user activity patterns, attribute actions to specific accounts, and map resource consumption with a level of temporal and contextual precision that is often unattainable through conventional artifacts alone. In environments where counter-forensic measures have been employed to delete logs, executables, or prefetch data, SRUM frequently remains the sole reliable source capable of illuminating application usage, network interactions, and system behavior.

In its initial implementation with Windows 8, SRUM collected performance and usage data for desktop applications, system utilities, background services, and Windows Store (Metro) applications. This telemetry was first staged in the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM before being transferred to the underlying Extensible Storage Engine (ESE) database (SRUDB.dat) at approximately 60-minute intervals or during a clean system shutdown or reboot.

Beginning with Windows 10 and continuing through Windows 11, the ingestion architecture was refined: data is still flushed to the SRUM database on a nominal 60-minute cycle, yet intermediate staging in the registry no longer occurs. The SOFTWARE hive is now utilized exclusively to enumerate and identify the names of the various tables within SRUDB.dat, located at C:\Windows\System32\sru\SRUDB.dat under the Microsoft\Windows NT\CurrentVersion\SRUM\Extensions path.

Forensic testing further reveals that, starting with Windows 10 version 2004 and persisting in Windows 11, SRUM data is not reliably written to disk during system shutdown. In observed test cases involving multiple rapid shutdowns within short intervals (e.g., two shutdowns less than 10 minutes apart), records were not committed until a subsequent boot followed by sustained runtime exceeding the 60-minute aggregation window from the prior entry.

This write-timing behavior carries significant evidentiary implications and warrants careful consideration during timeline analysis. SRUM entries frequently display identical timestamps (down to the second) corresponding to the moment of database commit rather than the actual period of activity. Examiners must therefore interpret each record as representing cumulative activity occurring in the interval between the current entry and the preceding one. Deviations from the standard ~60-minute cadence—whether shorter or longer—often signal system shutdown, hibernation, or irregular power events. Many analysts find it beneficial to compute inter-entry time deltas and apply conditional formatting in spreadsheet applications (such as Excel) to visually flag anomalies falling outside the expected window (±10 minutes).

SRUM retains historical data for approximately 30 days under normal conditions, though up to 60 days of records are commonly observed before automated purging. A notable exception is the Energy Usage LT (Long-Term) table, which preserves high-level telemetry on AC versus battery (DC) power utilization for extended periods. In examined cases, this table has yielded actionable data spanning more than four years, providing valuable insight into long-term system power-state history.

Forensic testing on Windows 10 and Windows 11 has demonstrated that when a system remains powered off for an extended period (on the order of weeks), SRUM data exceeding the standard 30-day retention threshold is typically purged immediately upon reboot. However, because the SRUM database (SRUDB.dat) is captured within Volume Shadow Copies, examiners can frequently recover historical versions of the database when shadow copy artifacts remain available on the system.

In typical incident response scenarios, where systems are rarely shut down cleanly, the SRUM database is often found in a corrupt or “dirty” shutdown state. Windows provides the built-in esentutl.exe utility to address such issues, supporting ESE database defragmentation, recovery, integrity verification, data dumping, and repair operations. Additionally, when records have been deleted from the SRUM database, practitioners may recover residual data using the specialized carving utility EseCarve.

When performing repairs on ESE databases, it is critical to execute the process on a system running the same Windows version and build as the source evidence to avoid compatibility-induced corruption. To determine whether the SRUM database was closed in a dirty state, analysts should first execute the following command:

esentutl /mh SRUDB.dat

To repair a dirty SRUM database, the recommended command is:

esentutl /p SRUDB.dat

These procedures significantly enhance the recoverability of SRUM artifacts in compromised or improperly powered-off environments, reinforcing its value as a resilient forensic resource.

Under the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM, three primary subkeys exist: Extensions, Parameters, and Telemetry. The Extensions subkey is of particular forensic value, as it enumerates the GUIDs corresponding to each SRUM database table and provides essential context regarding the data schema and telemetry types stored therein.

The following nine Extensions subkeys are present in Windows 10 version 1803 through Windows 11 and map directly to the tables within the SRUDB.dat database:

• {5C8CF1C7-7257-4F13-B223-970EF5939312} — App Timeline Provider (introduced in 1803)
• {7ACBBAA3-D029-4BE4-9A7A-0885927F1D8F} — Vfuprov (introduced in 1803)
• {973F5D5C-1D90-4944-BE8E-24B94231A174} — Network Data Usage Monitor
• {B6D82AF1-F780-4E17-8077-6CB9AD8A6FC4} — Tagged Energy Provider (introduced in 1803)
• {d10ca2fe-6fcf-4f6d-848e-b2e99266fa86} — WPN Srum Provider (Windows Push Notifications)
• {d10ca2fe-6fcf-4f6d-848e-b2e99266fa89} — Application Resource Usage Provider
• {DA73FB89-2BEA-4DDC-86B8-6E048C6DA477} — Energy Estimation Provider (introduced in 1803)
• {DD6636C4-8929-4683-974E-22C046A43763} — Network Connectivity Usage Monitor
• {FEE4E14F-02A9-4550-B5CE-5FA2DA202E37} — Energy Usage Provider

In Windows 11, the SRUM schema underwent a minor modification: the Energy Usage Provider table ({FEE4E14F-02A9-4550-B5CE-5FA2DA202E37}) received two additional columns — “Battery Count” and “Battery Charge Limit.” Forensic testing has determined that neither column provides significant analytical value in typical investigations.

SRUM was originally introduced with Windows 8 and has undergone incremental schema evolution across subsequent releases. Notable additions include the Windows Connectivity Usage Monitor in Windows 8.1 and the Energy Estimation Provider in Windows 10 version 1511. The GUIDs and structure of certain Energy Estimation Provider extensions continued to evolve through later Windows 10 builds. Examiners should reference the Extensions subkey during analysis to accurately map table contents to the specific Windows version under examination.

The Energy Estimation Provider Extensions subkey evolved across early Windows 10 releases as follows:

• In version 1511: {97C2CE28-A37B-4920-B1E9-8B76CD341EC5}
• In version 1607: {7899D64F-AB81-45E3-BE32-026FA9504937}
• In version 1803: {DA73FB89-2BEA-4DDC-86B8-6E048C6DA477} (which remains in current Windows 10 and Windows 11 builds).

Of the nine active Extensions subkeys (and their corresponding tables in the SRUM database) present in Windows 10 and Windows 11, four were introduced in Windows 10 version 1803:

• {5C8CF1C7-7257-4F13-B223-970EF5939312} — App Timeline Provider
• {7ACBBAA3-D029-4BE4-9A7A-0885927F1D8F} — Vfuprov
• {B6D82AF1-F780-4E17-8077-6CB9AD8A6FC4} — Tagged Energy Provider
• {DA73FB89-2BEA-4DDC-86B8-6E048C6DA477} — Energy Estimation Provider

While further research is warranted into the forensic utility of these newer tables, current analysis indicates that the majority of high-value evidentiary data continues to reside in three long-standing tables: the Network Connectivity Usage table, the Network Data Usage table, and the Application Resource Usage table. These tables consistently provide the most actionable insights regarding network affiliations, data transfer volumes, application execution, and user attribution.

The NirSoft utility ESEDatabaseView provides digital forensic examiners with a straightforward interface for browsing the SRUM Extensible Storage Engine database (SRUDB.dat). Upon opening the database, analysts are presented with its constituent tables—in the example above, there are 16. It could be more depending on the Windows version. By default, the MSysObjects table is displayed and sorted by the first column; column headers may be clicked to re-sort data by any desired field.

A dropdown selector located beneath the toolbar enables rapid navigation among all available tables within the database. For example, selecting the Network Data Usage table (GUID: {973F5D5C-1D90-4944-BE8E-24B94231A174}) allows direct examination of network utilization telemetry.

Of particular forensic significance is the Network Connectivity Usage table (GUID: {DD6636C4-8929-4683-974E-22C046A43763}), which records comprehensive details for each network connection, including the network identifier (e.g., SSID for wireless networks), connection start time, connection duration, and the specific interface utilized (such as wireless, wired Ethernet, or Point-to-Point Protocol). This data facilitates precise reconstruction of network activity timelines and supports attribution of system connectivity events even when other logging mechanisms have been cleared or are unavailable.

Examination of the Network Data Usage table (GUID: {973F5D5C-1D90-4944-BE8E-24B94231A174}) reveals extensive records of network utilization across all interfaces to which the system has connected. Each record includes an AppID field that identifies the specific application responsible for network activity during the corresponding hourly aggregation period.

The AppID value maintains a direct relational mapping to the IdIndex field within the SruDbIdMapTable. By cross-referencing this index, examiners can resolve the IdBlob field, which stores a Unicode string containing the full drive path and executable name of the associated binary. Additional high-value fields in this table include the UserId (SID), InterfaceLuid (identifying the network interface type), L2ProfileId (network profile identifier), and granular metrics for bytes sent and bytes received by the application during the recorded interval.

Value	Meaning
IF_TYPE_OTHER 1	Some other type of network interface.
IF_TYPE_ETHERNET_CSMACD 6	An Ethernet network interface.
IF_TYPE_ISO88025_TOKENRING 9	A token ring network interface.
IF_TYPE_PPP 23	A PPP network interface.
IF_TYPE_SOFTWARE_LOOPBACK 24	A software loopback network interface.
IF_TYPE_ATM 37	An ATM network interface.
IF_TYPE_IEEE80211 71	An IEEE 802.11 wireless network interface.
IF_TYPE_TUNNEL 131	A tunnel-type encapsulation network interface.
IF_TYPE_IEEE1394 144	An IEEE 1394 (Firewire) high-performance serial bus network interface.

Highlighted in the above figure is a network with a profile identifier of 268435474. To resolve the human-readable network name (such as an SSID) associated with a given L2ProfileId, analysts must cross-reference the identifier against the SOFTWARE registry hive, specifically within the network profile configuration keys. This correlation enables precise attribution of network activity to specific wireless or wired environments, significantly enhancing timeline reconstruction and geolocation inference in investigative contexts.

Forensic examiners will recall from the analysis of the Windows Registry—specifically within the HKLM\SOFTWARE hive—that various keys provide valuable indicators of historical network connections. Building upon this foundation, the registry path HKLM\SOFTWARE\Microsoft\WlanSvc\Interfaces serves as a critical reference for resolving SRUM-derived L2ProfileId values to their corresponding human-readable network names (primarily SSIDs for wireless networks).

Under this key, one or more Interface GUID subkeys will be present. In Windows 8 and Windows 8.1, the wireless interface GUID was consistently {DE6EA13E-5E9B-4CD7-9FA2-3F0F90CA70A9} across systems. Beginning with Windows 10 version 1909 and extending through Windows 11, this identifier is randomized on a per-machine basis, resulting in unique GUIDs that differ between installations.

In practice, examiners should focus on the Interface GUID containing a Profiles subkey, which typically houses the network profile records. These profiles include SSID mappings, connection metadata, and profile identifiers that directly correlate with the L2ProfileId values recorded in SRUM’s Network Connectivity Usage Monitor and Network Data Usage Monitor tables. This cross-referencing enables precise attribution of network activity to specific access points, significantly strengthening temporal reconstruction and contextual analysis even in the absence of other logging artifacts.

In the figure above, the active wireless Interface GUID is {63A2D21E-AE08-4EDD-8429-EABDA0A5EE5B}. Beneath the Profiles subkey, individual profile GUIDs are present for each network to which the system has historically connected. By examining each profile GUID and inspecting its ProfileIndex value, examiners can correlate the entry with the corresponding L2ProfileId observed in the SRUM database — in this instance, 268435474 from the Network Connectivity Usage Monitor table. One additional mapping step is required to resolve this identifier to a human-readable network name (typically the SSID stored in the ProfileName value).

In Windows 10 and Windows 11, L2ProfileId values are assigned sequentially beginning at 268435457 and incrementing with each new network first encountered by the system. Subsequent reconnections to the same network do not alter the assigned L2ProfileId. This sequential allocation enables forensic reconstruction of the chronological order in which networks were first accessed throughout the system’s operational lifecycle. Furthermore, the LastWrite timestamp associated with each profile GUID subkey records the first connection time to that particular network, providing a reliable temporal anchor for building accurate connection histories independent of SRUM’s hourly aggregation.

Once the profile GUID corresponding to the target ProfileIndex value (e.g., 268435474) has been identified—{63A2D21E-AE08-4EDD-8429-EABDA0A5EE5B} in this example—examiners should expand the profile GUID key and navigate to its Metadata subkey. Within this subkey, the Band Channel Hints value stores the network name (SSID) in hexadecimal format. This value can be conveniently viewed in human-readable form using the Type Viewer pane in tools such as Registry Explorer.

While specialized forensic utilities can automate the resolution of L2ProfileId values to SSIDs, a noteworthy analytical detail remains the registry timestamp behavior. The LastWrite timestamp of the Metadata subkey records the last connection time to that specific network.

Summary of Temporal Artifacts

• The LastWrite timestamp on the individual profile GUID key (SOFTWARE\Microsoft\WlanSvc\Interfaces\{Interface GUID}\Profiles\{Profile GUID}) corresponds to the first time the system connected to that network.
• The LastWrite timestamp on the associated Metadata subkey corresponds to the last time the system connected to that network.

This dual-timestamp mechanism provides forensic examiners with precise first-seen and last-seen connection chronology for each wireless network, offering valuable context that complements the hourly aggregation data resident in the SRUM database.

Thanks to the free SRUM_DUMP utility developed by Mark Baggett, forensic examiners are spared the labor-intensive process of manually parsing and decoding the numerous fields within the SRUM Extensible Storage Engine database. Mark Baggett, a SANS Senior Instructor and author of the SANS course Automating Information Security with Python (SEC 573), created this powerful open-source tool to streamline SRUM analysis.

SRUM_DUMP ingests the SRUDB.dat ESE database and generates a comprehensive Microsoft Excel workbook containing a dedicated worksheet for each table present in the database. The tool also includes customizable Excel spreadsheet templates that analysts can readily adapt to enhance data presentation and analytical efficiency—such as calculating network connection durations, implementing conditional formatting to highlight temporal anomalies, or deriving additional derived metrics.

Beyond raw data export, SRUM_DUMP performs valuable automated correlation by cross-referencing fields with the Windows Registry. This includes resolving L2ProfileId values to their corresponding human-readable network names (SSIDs), mapping User SIDs to account names, and enriching other contextual identifiers. These capabilities significantly accelerate timeline reconstruction, user attribution, and network activity analysis while reducing the potential for interpretive errors in complex investigations.

In the SRUM_DUMP output for the Network Connectivity Usage table, several columns provide critical forensic context. Column B reflects the timestamp when the SRUM record was committed to the database (in this instance, entries from 2026-04-20 06:23:00 UTC and 2026-04-22 09:07:00 UTC). Column E identifies the network interface type, here consistently indicating Wireless 802.11 connectivity. Column F displays the resolved network name (derived from the L2ProfileId). Column G records the duration of each connection at the time of the SRUM entry, while Column H captures the ConnectStartTime—the actual initiation of the network session.

Analysis of these records shows the system connected to the “itel S18” wireless network on 2026-04-20 at 05:54:08 UTC for 68 seconds, followed by a subsequent connection at 06:00:13 UTC lasting 97 seconds. Overlapping connection entries for the same network are commonly observed. Such patterns typically indicate a single continuous session spanning multiple SRUM aggregation periods. In these cases, examiners should rely on the shared ConnectStartTime as the definitive session start and utilize the longest ConnectedTime value as the total session duration.

Additionally, when SRUM entry timestamps deviate from the standard ~60-minute (±10 minutes) cadence, this strongly suggests intervening system shutdown, hibernation, or sleep states. In investigative contexts, these artifacts may corroborate hypotheses such as physical relocation with automatic network handoff to a stronger signal, or anomalous connectivity behavior potentially indicative of user attempts to connect to one network while being redirected to another.

The Network Connectivity Usage table serves as a robust source for reconstructing user movement patterns and geolocation inferences based on known wireless access points. For example, recurring connections to a specific coffee shop SSID could substantiate allegations of an employee utilizing that location’s Wi-Fi for unauthorized or malicious activities, thereby strengthening attribution and timeline narratives in insider threat or data exfiltration cases.

Another table frequently examined in SRUM_DUMP output is the Network Data Usage table (GUID: {973F5D5C-1D90-4944-BE8E-24B94231A174}). This table provides detailed telemetry on network utilization, including the specific networks to which the system was connected, the full executable path of applications and services active during the preceding SRUM aggregation interval (typically ~60 minutes), the aggregate bytes sent and received by each application across the network, and the associated User SID responsible for process execution.

It is important to note that SRUM records raw sent and received byte counts at the application or service level. These figures incorporate protocol overhead, retransmissions, and compressed data, and therefore may not correspond precisely to the actual size of individual files transferred.

This table is particularly valuable when reconstructing activity during a discrete temporal window. In the example above, the data illustrates which applications utilized the previously identified “itel S18” wireless network, with Column C listing the executables, Column H showing bytes sent, and Column I showing bytes received. Column D identifies the User SID associated with each application’s network activity.

To assess potential anomalous behavior, analysts can apply filters to Column C for specific application names of interest, enabling rapid identification of unusual network utilization patterns across other time periods. This capability supports efficient detection of data exfiltration, covert communication, or unauthorized application usage even when traditional log sources have been cleared.

A final table of significant forensic value in the SRUM_DUMP output is the Application Resource Usage table (GUID: {d10ca2fe-6fcf-4f6d-848e-b2e99266fa89}). Unlike the Network Data Usage Monitor table, which is limited to network-utilizing processes, this table comprehensively records the execution of all applications and services active during each hourly aggregation period.

The table captures the drive volume, directory path, and full executable path of each application, along with the associated User SID responsible for launching the process. Additional telemetry includes foreground and background CPU cycle consumption, as well as foreground and background disk I/O metrics (bytes read and written). These resource utilization fields can assist examiners in distinguishing between actively used applications and those running in an idle or background state, potentially indicating resource-intensive operations such as data processing, encryption, or exfiltration activity.

While the table contains a wealth of additional columns, many require further empirical validation before they can support definitive interpretive conclusions in investigative or courtroom contexts. In particular, the foreground and background bytes read/written fields show promise for inferring data movement activities—such as copying files to external storage devices—but current research remains insufficient to establish their reliability across all scenarios. Analysts should therefore exercise appropriate caution and seek corroboration from other artifacts when relying on these values.

At present, the primary evidentiary strength of the Application Resource Usage table lies in its reliable documentation of application execution timelines across each recorded hour. It serves as an excellent source for confirming and expanding upon findings from the Network Data Usage table, enabling more complete reconstruction of user activity, process attribution, and system behavior even in environments where counter-forensic techniques have been employed.

The System Resource Usage Monitor (SRUM) represents a multifaceted and resilient forensic artifact that holds substantial evidentiary value across nearly all digital investigations. It is particularly indispensable in cases involving counter-forensic techniques, where traditional artifacts such as event logs, prefetch files, or deleted executables have been intentionally obscured or removed.

Although the volume and complexity of SRUM data may initially appear daunting to less experienced examiners, seasoned digital forensic analysts prioritize three core categories of information:

• Application execution — which programs were launched and when;
• Network activity — connectivity details and data transfer volumes;
• User attribution — the specific Security Identifier (SID) responsible for each action.

The Network Data Usage table (GUID: {973F5D5C-1D90-4944-BE8E-24B94231A174}) is the primary source for quantifying network utilization. It documents the volume of data sent and received by each application during the preceding hourly interval, along with the associated network interface. As its name implies, this table is limited to processes that generated network traffic; applications executed without transmitting or receiving data will not appear.

Complementing this is the Network Connectivity Usage table (GUID: {DD6636C4-8929-4683-974E-22C046A43763}), which supplies critical temporal context. It records the start time of each network connection, the duration of connectivity at the moment of SRUM entry, and related interface details. These records frequently serve as valuable corroborative evidence when cross-referenced with registry-based network profiles or Windows event logs.

Finally, the Application Resource Usage table (GUID: {d10ca2fe-6fcf-4f6d-848e-b2e99266fa89}) functions as the cornerstone for comprehensive application execution timelines. It captures every application and service active during each hourly aggregation window—regardless of network activity—along with the responsible User SID. Given SRUM’s roughly hourly recording cadence and typical retention of 30–60 days, this table enables examiners to reconstruct application usage patterns with a temporal precision of approximately ±59 minutes across an extended historical period.

Collectively, these tables empower forensic practitioners to establish robust timelines, attribute actions to specific users, and uncover activity that would otherwise remain concealed following counter-forensic efforts.