Evidence of Execution: FeatureUsage Forensics




FeatureUsage constitutes one of the most significant forensic artifacts identified in post-Windows 10 builds, having first appeared in build 1903. Initially publicly analyzed and reported by Jai Minton, this per-user registry key—located at NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\FeatureUsage—provides high-granularity telemetry on both application execution and taskbar-centric user interactions that are largely unavailable through other conventional artifacts. Its subkeys deliver exceptionally detailed insights into user activity reconstruction, including:


  • AppLaunch: Execution counts for applications, particularly those interacting with the taskbar or pinned shortcuts.
  • AppSwitched: Frequency of focus switches, corresponding to user clicks on taskbar icons to foreground applications.
  • ShowJumpView: Interactions with Jump Lists (right-click menu invocations on taskbar entries), revealing application knowledge and recent file access patterns.
  • TrayButtonClicked: Direct clicks on various taskbar elements such as the system clock, Start button, Notification Center, and Search interface.
  • AppBadgeUpdated: Badge (notification count) updates on taskbar icons.


Although these artifacts are not exhaustive—they predominantly capture GUI-oriented and taskbar-mediated activities and generally require an interactive logon session (console or RDP) for population—they afford investigators click-level visibility into user behavior that complements and corroborates other sources such as UserAssist, BAM, SRUM, and Jump Lists. Notably, the data exhibits strong persistence: entries are not purged upon application uninstallation, enabling the recovery of detailed usage telemetry for privacy tools, chat clients, VPN applications, and other items of interest long after the executables have been removed from the system. This combination of longevity, specificity, and uniqueness makes FeatureUsage a high-value registry artifact in timeline analysis and user activity reconstruction



AppLaunch and AppSwitched represent the most probative subkeys within the FeatureUsage registry artifact for digital forensic examiners, offering complementary yet distinct perspectives on user-driven application interaction.

AppLaunch specifically enumerates execution counts for applications that have been pinned to the taskbar. Pinning inherently demonstrates deliberate user knowledge of, and intent toward, the application, as it requires an affirmative action to place and retain the shortcut on the taskbar for persistent access. Values within this subkey record the full executable path (frequently incorporating KNOWNFOLDERID GUIDs for well-known shell folders, consistent with UserAssist encoding) alongside a DWORD counter reflecting the total number of launches via the pinned shortcut. In the example above, you can see Windows Explorer appears to be the pinned application with the most executions (shortcut clicks). Critically, these entries exhibit strong persistence: records remain intact even after the application is unpinned or uninstalled, preserving evidence of historical usage. This enables identification of executables launched from anomalous or evasive paths (e.g., temporary directories, AppData subfolders, or non-standard locations), which is particularly valuable when correlating with malware persistence mechanisms or privacy tool deployment.

AppSwitched, by contrast, provides broader coverage, often encompassing the majority of GUI applications that have achieved foreground focus on the system. Untethered from pinning requirements, it tallies the number of times an application was brought into active focus—typically via left-clicking its taskbar icon—thereby indicating periods during which keyboard and mouse input were directed to that process. As a fundamentally graphical construct, it is limited to GUI applications and reliably captures installer wizards, setup executables, and other interactive binaries that require sustained user attention. In this example, it appears that NTFS Log Tracker v1.2.exe was by far the most in-focus application on the system. In investigative scenarios, elevated counts for tools such as credential-harvesting utilities or unauthorized applications can powerfully rebut claims of minimal knowledge or usage, furnishing quantitative evidence of deliberate, repeated engagement.



AppBadgeUpdated constitutes a supplementary yet uniquely valuable subkey within the FeatureUsage registry key, furnishing telemetry unavailable in other standard artifacts.

This subkey enumerates the cumulative number of badge (notification count) updates displayed on taskbar icons for individual applications. Taskbar badges—commonly observed as numeric overlays on application icons—serve as visual indicators of pending notifications, messages, or events. You can see an example of a WhatsApp icon with a badge showing 99+ new messages in the figure above. Looking at the AppBadgeUpdated values for that system, you can see a very active user with 13,191 total notifications to the user. While more prevalent in mobile ecosystems, they are prominently utilized by modern Windows desktop applications such as messaging clients (WhatsApp, Teams, Slack), email clients, and social media tools. In forensic examinations, a high aggregate count (such as 13,191 badge updates for WhatsApp) provides quantitative insight into the frequency of background activity, notification volume, and overall user engagement with the application, even when direct execution or focus data is limited.

Forensically, AppBadgeUpdated entries typically consist of executable paths (often resolved via KNOWNFOLDERID GUIDs) paired with DWORD counters that increment with each badge refresh. Like its sibling subkeys, data persists indefinitely and is not purged upon application uninstallation or taskbar unpinning. This longevity is particularly probative when investigating communication tools, collaboration software, or any application that generates frequent notifications, as it can corroborate patterns of sustained use, potential exfiltration activity, or attempts to maintain covert channels.

Although less granular than the execution and focus metrics provided by AppLaunch and AppSwitched, this subkey enhances timeline reconstruction and user behavior profiling by illuminating passive engagement and notification-driven interaction that might otherwise remain invisible in Prefetch, SRUM, or Event Logs. When analyzed in conjunction with the other FeatureUsage subkeys, it contributes to a more comprehensive understanding of application lifecycle and user attention allocation on the system.


ShowJumpView and TrayButtonClicked represent additional high-value subkeys under the FeatureUsage registry artifact. Although generally less voluminous than AppLaunch and AppSwitched, they deliver interaction telemetry unavailable through conventional Windows forensic sources.

ShowJumpView records the number of times a user has right-clicked a taskbar icon to invoke the application’s Jump List. This action demonstrates deliberate, deeper engagement with the application beyond simple launching or foregrounding, as Jump Lists expose recent files, tasks, and destinations associated with the program. Each value typically stores the executable path (often resolved via KNOWNFOLDERID GUIDs) paired with a DWORD counter that increments with every invocation. Elevated counts (such as eight right-clicks on a cmder shortcut seen in the figure above)—provide strong indicators of repeated, intentional use of the application and its associated Jump List content (e.g., frequent access to command-line utilities, documents, or specific workflows). Forensically, this subkey is particularly useful for establishing user familiarity with tools that support rich Jump List integration and for correlating with file access artifacts in RecentFileCache, AutomaticDestinations, or CustomDestinations Jump List files.

TrayButtonClicked captures user interactions with non-application elements of the taskbar and notification area. It enumerates clicks on system widgets including the system clock, Start menu button, Search box, Cortana/Search interface, Notification Center, and related tray components. Each entry logs the specific UI element interacted with alongside a cumulative click count. This data yields exceptional visibility into low-level user behavior patterns, such as frequent time manipulation (correlatable with Event Log timestamp discrepancies), repeated search activity (revealing keywords or intent), or habitual navigation through the Start menu and notification system. In intrusion investigations involving compromised accounts or RDP sessions, high activity in this subkey can illuminate attacker reconnaissance, lateral movement, or data discovery behaviors that might otherwise be difficult to attribute.

As with all FeatureUsage subkeys, both ShowJumpView and TrayButtonClicked exhibit strong persistence: entries are retained even after applications are unpinned, uninstalled, or no longer present on the system. They are populated only during interactive sessions and focus exclusively on GUI/taskbar-mediated actions. When integrated with the broader FeatureUsage dataset and cross-referenced against UserAssist, SRUM, BAM, and Jump List artifacts, these keys significantly enrich user activity timelines and behavioral reconstructions.


At the root of the FeatureUsage key resides the KeyCreationTime value (REG_QWORD), which records the precise timestamp of the initial interactive logon in Windows FILETIME format—a 64-bit unsigned integer representing the number of 100-nanosecond intervals elapsed since 1601-01-01 UTC. This artifact furnishes digital forensic investigators with a reliable temporal indicator of the earliest interactive presence of a user account on the target system.

Conversion of the FILETIME value to a human-readable timestamp is straightforward using tools such as CyberChef (via intermediate Unix epoch conversion), Python’s datetime module, or dedicated registry parsers. Analysts should also examine the key’s own LastWrite timestamp for supplementary context.

From a DFIR perspective, KeyCreationTime serves as a resilient artifact in intrusion investigations involving compromised accounts or RDP access. It is particularly probative when adversaries have engaged in anti-forensic activities—such as clearing Windows Event Logs (Security.evtx) or other high-visibility artifacts—allowing examiners to corroborate or establish the approximate onset of “hands-on-keyboard” adversary activity. While not a substitute for centralized logging or EDR telemetry, this key can materially support timeline reconstruction and attribution when primary sources have been tampered with or rendered unavailable.

Post a Comment

Previous Post Next Post