Technical reference for Experts
and Auxiliary Justice Personnel
The purpose of this document is to provide forensic examiners with a structured technical guide to identify software that has been installed and uninstalled on Windows systems, with a particular focus on:
The guide focuses on modern versions of Windows (10 and 11), but many of the artefacts described also exist in earlier versions (Windows 7 and 8). The approach combines:
Throughout the text, suggested locations for including screenshots are indicated for use in reports and training materials. The paths and procedures described are based on official Microsoft documentation and reference technical articles published by the digital forensics community.
On a typical Windows system, the existence and installation of software leave traces at multiple levels:
The remainder of the paper explains how to use each of these artefacts and how to correlate them in order to answer three key questions:
Although forensic analysis should ultimately be grounded in low level artefacts, the Windows graphical interface is still a useful starting point to obtain a quick view of the software currently installed.
Typical path:
The list shows programs and apps with information about the publisher and, in some cases, the installation date recorded by the installer.
| Name | Publisher |
|---|---|
| Google Chrome | Google LLC |
| Microsoft Edge | Microsoft Corporation |
| Microsoft OneDrive | Microsoft Corporation |
| Mozilla Firefox | Mozilla |
| Notepad | Microsoft Corporation |
| Paint | Microsoft Corporation |
| VLC media player | VideoLAN |
This view has important limitations: it only lists software that is currently installed, there is no uninstallation history, the installation date is not always present or reliable and many portable tools or standalone executables (without a formal installer) do not appear here.
Although less visible in recent versions, the classic Control Panel still exists and offers a similar view:
The resulting list contains programs installed through different types of installers. For each entry, the following may be displayed: product name, publisher, installation date, version and approximate size.
| Name | Publisher | Installed on |
|---|---|---|
| Adobe Acrobat DC (64-bit) | Adobe Inc. | 31/03/2024 |
| Dropbox | Dropbox Technologies LLC | 05/01/2024 |
| Google Chrome | Google LLC | 09/04/2024 |
| Microsoft Edge | Microsoft Corporation | 16/03/2024 |
| Microsoft Excel | Microsoft Corporation | 26/12/2023 |
| Microsoft OneDrive | Microsoft Corporation | 21/02/2024 |
| Microsoft Word | Microsoft Corporation | 05/01/2024 |
| Mozilla Firefox | Mozilla | 09/04/2024 |
| Skype | Skype | 23/04/2024 |
| VLC media player | VideoLAN | 09/04/2024 |
Again, this is only a snapshot of the current state, not a historical record. To reconstruct the past and detect uninstallations it is necessary to move towards deeper artefacts.
The Windows Registry is a hierarchical database where the operating system and applications store configuration data. Forensic studies have repeatedly demonstrated that the keys related to software installation are a source of high evidentiary value.
The main locations where Windows and many applications store information about installed software are:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UninstallHKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall (for many 32-bit applications on 64-bit systems)HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (user-specific installations)These paths are widely documented in technical literature and forensic guides on installed programs.
Not all applications populate all of these values; in many cases InstallDate is blank. The existence of a subkey under Uninstall is a strong indication that the program was installed, but it does not guarantee that it is still present on disk; some uninstallers delete the key, others do not.
In addition to the visible values, each registry subkey has a LastWrite time (last modification time), which can be obtained using forensic tools. This timestamp can provide additional information. When the subkey is created at installation time, the LastWrite typically coincides with the installation date. If the application is uninstalled and the key is deleted, the examiner will have to reconstruct its existence from other sources such as Prefetch, AmCache or event logs. If uninstallation only modifies certain values (for example, a state flag), the LastWrite may be close to the uninstallation date.
Forensic analyses of the registry have shown that even after a program is uninstalled, residual values linked to that application may remain in different parts of the registry, especially when the uninstaller does not thoroughly clean the configuration. This includes entries under HKLM and HKCU that are not removed, application specific settings under HKCU\SOFTWARE\<Vendor> and file association or shell related keys under HKCR/HKEY_CLASSES_ROOT.
For reports, it is advisable to document with screenshots and .reg exports the subkeys of interest and to record the LastWrite time of those subkeys using forensic tools rather than relying solely on what regedit displays. In this way, the registry contributes evidence of existence and configuration of the software, even when other traces have been partially removed.
Windows event logs are another key source for reconstructing the installation and uninstallation history, particularly for software that uses the Windows Installer (MSI) service.
Windows records many installation and uninstallation operations in the Application log under the source MsiInstaller. Technical documentation and specialized articles highlight, among others, the following event IDs as relevant:
Recent guides on installation and removal history in Windows describe how to find these events in Event Viewer and use them as a chronological record of software changes.
Each event contains details such as the precise date and time of the operation, product name, version, the user who initiated the installation or uninstallation (when available) and the product code (GUID) associated with the MSI package.
It is important to stress that not all software uses Windows Installer. Many installers based on custom executables (.exe) do not generate MsiInstaller events. In those cases, the event logs will be partial or absent and other artefacts such as Prefetch and AmCache gain importance.
For a rigorous analysis, it is good practice to export filtered events to an .evtx or .csv file and then sort the operations chronologically, identify patterns such as repeated install/uninstall cycles for the same product and correlate timestamps with procedural milestones (the date of the search, the creation of the forensic image and so on). When investigating a possible last minute uninstallation, a 11724 event recorded shortly before the time of seizure of the equipment is a relevant point to highlight in the report.
The presence of registry keys and installation logs does not exhaust the available evidence. Windows maintains several artefacts originally designed for performance or compatibility that, from a forensic perspective, provide historical evidence of program execution even when the software is no longer installed.
Prefetch files were designed to speed up application startup. Forensic guides describe their behaviour in summary as follows. When an executable is run for the first time from a given path, Windows creates a .pf file under C:\Windows\Prefetch. The file name combines the executable name and a hash of the execution path (for example, APPNAME.EXE-12345678.pf). The file stores, among other data, timestamps for first and last recorded run and a run count.
From an evidential perspective, this is important because Prefetch files may remain after the program has been uninstalled, as long as the Windows limit for stored entries is not exceeded (in recent versions, up to roughly 1024 files). Even if the executable is no longer present on disk, the existence of a .pf file shows that the program existed at a given path and was executed a certain number of times. The last run timestamp can help establish a timeline, particularly when correlated with other artefacts.
| Name | Date modified | Type |
|---|---|---|
| 7-ZIP.DLL-7428688F.pf | 22/04/2024 12:17 p.m. | PF File |
| CHROME.EXE-7B0683C.pf | 23/04/2024 12:17 p.m. | PF File |
| EXPLORER.EXE-28F6CF77.pf | 22/04/2024 12:17 p.m. | PF File |
| FIREFOX.EXE-11BE7758.pf | 22/04/2024 12:17 p.m. | PF File |
| NOTEPAD.EXE-9D56FCAF.pf | 22/04/2024 12:17 p.m. | PF File |
| SERVICES.EXE-32D1A1BD.pf | 22/04/2024 12:17 p.m. | PF File |
Limitations include the fact that users or "cleanup" tools can empty C:\Windows\Prefetch, disk replacement or system reinstallation can remove this artefact and group policy settings can disable Prefetch. In addition, Prefetch does not usually record who ran the application, only that it was run.
AmCache and ShimCache (also known as AppCompatCache) are other artefacts that have been extensively studied in Windows forensic literature. In brief, AmCache is a registry hive (Amcache.hve, typically located in C:\Windows\AppCompat\Programs\) that stores information about executed programs, including the executable path, file hashes (for example SHA-1) and timestamps linked to installation, first execution and, in many cases, file deletion. ShimCache records information about executables loaded by the system for compatibility purposes. Although its timestamps are not always reliable, it offers a historical view of programs that were present.
Beyond the specific artefacts above, the forensic literature emphasizes that the existence of a program and its subsequent removal may leave traces in:
These analyses require specific forensic tools and exceed the purpose of a first-level inspection, but it is worth mentioning them in technical reports to explain why it is possible to find evidence of a program even though it has been uninstalled or deleted.
In many investigations, especially in criminal or intellectual property matters, the hypothesis arises that the subject uninstalled or deleted software shortly before a search or judicial seizure with the intention of making proof difficult. The expert's task is not to presume intentions, but to objectively document technical indications that can support or rule out this hypothesis.
If the software was installed via Windows Installer, MsiInstaller events offer a robust starting point:
In forensic reports, it is especially useful to construct a timeline in which the following are placed on the same temporal scale:
Another strategy is to compare the current state (programs actually present on disk and listed in Uninstall) with the historical execution artefacts:
Often, hasty uninstallations leave partial traces in the registry:
HKCU\SOFTWARE\<Vendor> that are rarely cleaned by automated uninstallers;The correlation of these residues with other artefacts allows the examiner to corroborate the existence of the software and, in many cases, establish an approximate timeline of its removal.
When preparing a forensic report on potentially uninstalled software, it is advisable to:
The identification of software that has been installed and subsequently uninstalled from a Windows system is a complex but achievable task when the examiner uses a combination of native system tools and well-documented forensic artefacts. The registry, event logs, Prefetch files, AmCache and ShimCache together provide a multi-layered view of software presence and activity that can survive even deliberate attempts at concealment.
This guide has presented a structured approach to locating, documenting and interpreting these artefacts, with particular emphasis on detecting last-minute uninstallations. By correlating timestamps, analyzing residual traces and constructing detailed timelines, forensic examiners can provide objective, reproducible evidence that supports judicial proceedings and contributes to the pursuit of truth and justice.
The techniques and procedures described in this document are based on:
Examiners are encouraged to stay current with evolving forensic techniques and to validate their findings using multiple independent methods whenever possible.
— End of Document —