This guide continues our ongoing series exploring digital artifacts found on Windows computers and their practical meaning during an investigation. With each new topic, the puzzle becomes more complex because these traces rarely exist in isolation. Modern forensic best practices rely heavily on cross-checking different types of artifacts against one another. By connecting these dots, investigators do more than just establish isolated facts – they build a solid, reliable conclusion that can stand up in court.

Here, we turn our attention to the architectural core of the OS. We concentrate entirely on the non-user-specific system files generated natively by Windows 10 and Windows 11, primarily those located under the C:\Windows path. By analyzing these artifacts, investigators can uncover evidence showing exactly what programs were run, whether data was stolen, and even clues about a user’s physical presence at the keyboard.

We intentionally ignore several major components to maintain a targeted focus. Files representing Windows Registry hives and Windows Event Logs (.evtx) are out of scope; check out forensic analysis of Windows 10 and 11 Event Logs and investigating the Windows Registry. We also omit files created by third-party or non-system programs, including artifacts generated by native software like Microsoft Edge, unless stored under the system root. Finally, the C:\ProgramData\ directory – housing non-user-specific application configurations and data like the Windows Search Index – is excluded and will be covered in a separate blog post.

Note: This guide assumes a solid understanding of Windows internals, file system structures, and standard forensic collection methods. It is designed as a practical technical reference for experienced examiners and security researchers conducting deep-dive analysis. Keep in mind that artifact behavior and its evidentiary value can shift depending on the specific OS build, edition (client vs. server), audit policies, logging configurations, retention limits, and hardware support (like Modern Standby). Always validate these variables on your target system before drawing firm conclusions.

Environment Variables

A practical rule in this field is that hardcoded paths are not always what they look like. Relying on the absolute path C:\Windows\ during live triage or automated collection is a common source of errors if investigating a dual-boot setup or a complex deployment.

When investigating a live system, it’s best to start with Windows environment variables such as %windir% or %SystemRoot% instead of assuming C:\Windows. They resolve to the active system directory, even if Windows is installed in an unusual location. Windows also uses a number of hidden, system-managed special folders like %AppData% and %LocalAppData%, plus user root paths under %UserProfile% (or %HomeDrive%%HomePath%). Those folders contain lots of traces left by a specific Windows user. We’ll return to them in another article; for now, we’ll focus on system-wide artifacts under the Windows directory.

Noisy Artifacts

“Noise” is high-volume, constantly changing data that usually adds little value in broad triage. Digging through it can slow you down, clutter timelines, and create avoidable false positives. A good default is to exclude the items below – then keep or sample them when your case specifically involves that subsystem:

• System Temporary Files (%WinDir%\Temp\*): A catch-all for installer leftovers and app debris. It changes constantly, and timestamps here are often messy, which makes clean timeline work harder.
• Boot Performance Traces (%WinDir%\Prefetch\ReadyBoot\*.etl): Circular ETL files used to optimize boot via SuperFetch/SysMain. They roll over quickly and mostly contain performance-focused data, so they’re rarely the first place to look for execution attribution.
• Dynamic Performance Logs (%SystemDrive%\PerfLogs\*and %WinDir%\System32\LogFiles\WMI\*): These directories hold continuous, real-time hardware and software performance traces. They are generally low priority unless your case specifically involves resource abuse, performance tampering, or related instrumentation.
• Defender Service Caches (%WinDir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\Windows Defender\*): Defender updates and transient inspection files can generate thousands of artifacts. Useful for Defender-focused cases, but otherwise they tend to drown out higher-signal entries.

Core Windows File System Artifacts

System Resource Utilization Monitor (SRUM) Database

SRUM is one of the more useful system artifacts for understanding application and network activity over time. Depending on the tables you parse, it can help tie activity back to executables (including names/paths) and user SIDs, and it provides timeframe-based telemetry for usage and network behavior. Windows 10 and Windows 11 use SRUM as part of ongoing background diagnostics for things like network usage, battery, and application health. Telemetry is recorded at short intervals and written to an Extensible Storage Engine (ESE) database named srudb.dat. For a deeper dive, see Analyzing the Windows SRUM Database.

• Path: %WinDir%\System32\sru\SRUDB.dat
• The database tracks per-application byte usage counters (bytes sent and received), which can be very useful when investigating potential data exfiltration.
• SRUM can break usage out by network interface, helping you distinguish (for example) Wi-Fi transfers from corporate LAN activity.
• Historical usage may remain in the database even after an application is deleted.
• SRUM timestamps are best treated as activity windows or reporting intervals, not exact start/stop execution times.
• Cross-Correlation: Pair SRUM network activity with Windows Firewall Event Logs (e.g., Event ID 5156) to identify destination IP addresses, and review the SOFTWARE Registry hive for global network profile context.

Windows Prefetch Files

Windows Prefetch files are cache artifacts created by the Windows prefetching mechanism (Prefetcher/SysMain) to speed up application launches. During the early phase of execution (often described as roughly the first ten seconds), Windows tracks the files and memory pages an executable touches and writes a summary to disk.

• Path: %WinDir%\Prefetch\*.pf
• The presence of a .pf file is strong evidence that a specific binary ran on the system (with the usual artifact caveats).
• The file name typically includes the executable name plus an eight-character hash related to the path it ran from.
• In Windows 10 and Windows 11, Prefetch generally stores up to the last eight execution timestamps along with a recorded run count (parser/version caveats apply).
• If an attacker runs a payload and later deletes it, the .pf file may still remain, preserving useful historical traces until it is overwritten or removed.
• The internal structure lists directories and DLLs the executable interacted with, which can help spot potential DLL hijacking opportunities.
• Cross-Correlation: Compare Prefetch timestamps with Security.evtx Event ID 4688 (Process Creation), if process creation auditing is enabled, to identify parent process context. Use AmCache for additional executable metadata (including hash-related fields where available), and treat ShimCache/AppCompatCache as presence/execution-adjacent context rather than a hash source.

Program Compatibility Assistant (PCA) Databases

The PCA service (PcaSvc) monitors legacy applications and applies compatibility shims to keep older software working on newer Windows builds. In Windows 11 22H2 and later, researchers have documented text-based PCA telemetry files (for example, PcaAppLaunchDic.txt and PcaGeneralDb*.txt) within the appcompat area.

• Path: %WinDir%\appcompat\pca\PcaAppLaunchDic.txt and %WinDir%\appcompat\pca\PcaGeneralDb*.txt
• This artifact often captures GUI-initiated application launches, with important exceptions depending on how the process was started.
• Entries may include executable path details (sometimes partially redacted) alongside execution-related timestamps, typically in UTC-style formatting.
• Because it’s newer than many “classic” artifacts, some anti-forensic tooling may overlook it. It can help reconstruct GUI launches and may preserve paths to deleted tools, subject to rotation and retention limits.
• In some situations, PCA telemetry can also provide context around failed launches or compatibility checks – but treat this as case-dependent and corroborate it with other sources.
• Cross-Correlation: Correlate PCA entries with the NTUSER.DAT Registry hive (especially UserAssist) and line them up with Security.evtx Event ID 4624 (Successful Logon), where available, to support user attribution.

Windows Diagnostic Infrastructure (WDI) StartupInfo

The Windows Diagnostic Infrastructure (WDI) monitors system performance and diagnostics during the boot sequence. As part of this process, the StartupInfo mechanism records resource consumption data for applications launching at startup. These records are saved as XML files mapped to individual user Security Identifiers (SIDs) – typically found under %WinDir%\System32\WDI\LogFiles\StartupInfo\. The metrics captured in these logs include precise measurements of CPU time and disk input/output (I/O). These metrics affect values displayed in Task Manager – Startup apps – Startup impact. High impact apps are those consuming >1s CPU time or >3 MB disk I/O.

• Path: %WinDir%\System32\WDI\LogFiles\StartupInfo\<SID>_StartupInfo<index>.xml
• These files can record many processes observed during roughly the first 90 seconds after a user logs in.
• They often include start time, parent process details, and the command line used to launch the process.
• This makes StartupInfo a strong place to look for persistence that triggers shortly after authentication (including scripts launched quietly in the background).
• Cross-Correlation: Compare suspicious entries with the Run and RunOnce keys in NTUSER.DAT and SOFTWARE, and use Security.evtx Event ID 4624 to anchor the logon window.

Modern Standby and SleepStudy Traces

On systems that support Modern Standby (or where SleepStudy data is present), Windows produces SleepStudy-related ETLs and reports to track power state transitions and battery drain. Depending on the device and build, this can include files like UserNotPresentSession.etl.

• Path: %WinDir%\System32\SleepStudy\*.etl
• These traces can record timestamps for power and hardware state transitions, such as entering a low-power state and returning to active use.
• They can help assess device usage patterns and physical-access hypotheses, but they shouldn’t be treated as standalone proof.
• The logs may also highlight software components that kept the system awake, which can be useful when you suspect unexpected background activity.
• Cross-Correlation: Align SleepStudy transitions with relevant System log entries (including Kernel-Power events) to build a defensible timeline, and confirm exact providers/event IDs on the target build.

Windows Management Instrumentation (WMI) Repository

WMI is a core administrative framework that stores class definitions, instances, and event subscription components in proprietary binary repository files (including OBJECTS.DATA, INDEX.BTR, and MAPPING.MAP).

• Path: %WinDir%\System32\wbem\Repository\ (and %WinDir%\System32\wbem\AutoRecover\)
• This is a key place to check when you suspect WMI-based persistence, especially permanent event subscriptions.
• Attackers may create WMI Event Filters and Event Consumers to trigger commands when certain system conditions are met.
• Because subscription definitions and consumer properties may live inside the repository, analyzing it can reveal persistence logic that isn’t obvious from file-based scanning alone.
• Copies of malicious MOF files may show up in wbem\AutoRecover and can help re-establish persistence after repository rebuilds.
• Cross-Correlation: Correlate repository findings with Microsoft-Windows-WMI-Activity/Operational and Microsoft-Windows-PowerShell/Operational. PowerShell Event ID 4104 (Script Block Logging) is especially helpful when enabled and when relevant script blocks were captured.

SetupAPI Device and Application Logs

SetupAPI manages device and driver installation and writes chronological entries to logs such as setupapi.dev.log and setupapi.app.log.

• Path: %WinDir%\inf\setupapi.dev.log and %WinDir%\inf\setupapi.app.log
• These logs capture device and driver installation events and are often useful for estimating when a USB device was first installed on a system.
• They include signature verification steps for drivers, which can help highlight unsigned or improperly signed components.
• They provide a useful record of many hardware changes and related installations (and you’ll often want to normalize timezones during timeline work).
• Cross-Correlation: Pair SetupAPI timing with USBSTOR and MountedDevices in the SYSTEM hive to connect physical hardware to drive letters, and compare with ShellBags to support file-browsing activity.

Wi-Fi Event Trace Logs (WLAN AutoConfig)

Windows can keep circular ETL traces for wireless diagnostics (for example, Wifi.etl) tied to WLAN AutoConfig and related ETW providers.

• Path: %WinDir%\System32\LogFiles\WMI\Wifi.etl
• The trace can provide a detailed timeline of wireless activity, including authentications, roaming, and disconnect events.
• Extracted BSSIDs can support approximate geolocation or movement inference when paired with external BSSID reference data.
• Cross-Correlation: Correlate BSSIDs with the SOFTWARE hive (for example, Microsoft\Windows NT\CurrentVersion\NetworkList) to add longer-term context about saved and previously observed networks.

Software Usage Metrics (SUM) and User Access Logging (UAL) (Windows Server only)

UAL tracks incoming client requests to Windows Server roles and stores data in ESE databases under System32\LogFiles\Sum. It’s primarily a server artifact, but it’s worth calling out if you work in mixed client/server investigations.

• Path: %WinDir%\System32\LogFiles\Sum\
• On supported Windows Server systems, UAL can retain role/service access history for up to three years, often outlasting standard security log retention.
• Depending on role and configuration, it may record client identifiers, usernames, and timestamps related to service access.
• This can be a solid long-term ledger when investigating lateral movement or persistent intrusion on servers where primary logs were cleared or rotated.
• Cross-Correlation: Correlate IPs and accounts with boundary/network telemetry, and tie UAL timing to Security.evtx Event ID 4624 (for example, Logon Types 3 and 10) where relevant and available.

Low Priority Artifacts

The following artifacts are usually less critical for common cases like data theft or standard unauthorized access. They’re still worth knowing about, but they tend to offer lower return on time unless your hypothesis points directly to them.

Windows Setup and Panther Logs

The Panther engine generates logs (such as setupact.log and setuperr.log) that document Windows installation and upgrade activity.

• Path: %WinDir%\Panther\setupact.log and %WinDir%\Panther\setuperr.log
• They can provide a timeline of major system changes, setup decisions, and driver handling during installation/upgrade workflows.
• They’re most useful for spotting suspicious components introduced during updates or for tracking forced rollbacks.
• Cross-Correlation: Cross-reference driver activity with SetupAPI logs and the SYSTEM Registry hive.

Windows System Crash Dumps (Minidumps)

When the kernel hits a fatal exception, Windows can write crash data to disk, including small dump files in the Minidump directory.

• Path: %WinDir%\Minidump\*.dmp (and the full dump at %WinDir%\MEMORY.DMP)
• Minidumps are best for crash triage (bugchecks, stack traces, driver/process context) rather than full memory reconstruction.
• Stack traces can help pinpoint malicious or unstable drivers and may surface evidence of injected code in the crashing path.
• Cross-Correlation: Correlate dump timestamps with System.evtx Event ID 1001 (BugCheck).

AutoLogger Event Trace Logs

Some diagnostic subsystems skip Event Viewer and write directly to binary .etl files, such as AutoLogger-Diagtrack-Listener.etl.

• Path: %WinDir%\System32\LogFiles\WMI\AutoLogger-Diagtrack-Listener.etl
• Because these are “diagnostic” logs, clearing scripts may overlook them.
• They can provide partial but resilient visibility into subsystem behavior and timing, and sometimes preserve execution-adjacent context.
• Cross-Correlation: Compare with Security.evtx Event ID 1102 and other log-clearing events (for example, Event ID 104 in relevant logs) to bracket potential anti-forensic activity.

Windows Font Cache

Windows caches font metrics in binary files (such as FNTCACHE.DAT) to speed up rendering.

• Path: %WinDir%\System32\FNTCACHE.DAT
• Unexpected changes are a niche anomaly signal, not a standalone indicator of compromise.
• If you suspect font-related exploitation (for example, a malicious document chain), font cache anomalies can be worth reviewing alongside crashes and document-open activity.
• Cross-Correlation: Correlate anomalies with Application event logs for Font Cache Service issues and with user-activity artifacts (such as RecentDocs in NTUSER.DAT).

Conclusion

File system artifacts give you the raw material to reconstruct an incident, but the real value comes from connecting the dots across multiple sources. A Prefetch file may suggest execution; tying it to SRUM network telemetry and SetupAPI USB installation evidence can support a much stronger narrative around a potential exfiltration event.

Even the best forensic tools won’t make investigative decisions for you. Parsers can organize data, but interpreting intent, building a clean timeline, and supporting attribution still takes an investigator applying informed judgment. To streamline collection and save time for analysis, consider using Elcomsoft Quick Triage. We developed this utility to quickly collect a wide range of system artifacts from live systems, disk images, or mounted volumes – so you can spend more time on interpretation and case strategy.

We are grateful to the members of the forensic community whose research continues to drive the industry forward:

1. Forensic Analysis of Prefetch files in Windows (Magnet Forensics)
2. Diving into the Windows 11 Forensics PCA Artifact (Sygnia)
3. Investigating data exfiltration: key digital artifacts across Windows, Linux, and macOS (Magnet Forensics)
4. Who Left the Backdoor Open? Using Startupinfo for the Win (TrustedSec)
5. Modern standby SleepStudy (Microsoft Learn)
6. Finding Evil WMI Event Consumers with Disk Forensics (SANS Institute)
7. SUM UAL – Investigating Server Access with User Access Logging (The DFIR Spot)
8. Log files and resolving upgrade errors – Windows (Microsoft Learn)
9. Enabling Event Categories for a Text Log – Windows drivers (Microsoft Learn)
10. Windows Minidump Explained – What You Need to Know (Lenovo)
11. The Windows Forensic Journey — Wifi.etl (Medium)
12. Uncovering Hidden Forensic Evidence in Windows: The Mystery of AutoLogger-Diagtrack-Listener.etl (Fortinet)