Forensic Guide on
Uninstalled
Software in
Windows
Environments

Technical reference for Experts
and Auxiliary Justice Personnel

Dr. Christian A. Biniat

Microsoft Autodesk

1. Introduction and scope

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.

2. Overview of relevant Windows artefacts

On a typical Windows system, the existence and installation of software leave traces at multiple levels:

  1. Graphical interface and system utilities: lists of programs in Settings > Apps and in Control Panel > Programs and Features.
  2. Windows Registry: keys under the SOFTWARE hives and NTUSER.DAT that document installed applications, paths, versions and, in many cases, installation dates.
  3. Event logs: events generated by the Windows Installer (MSI) service that record installations, updates and uninstallations.
  4. Execution artefacts: Prefetch files, AmCache hives and compatibility caches (ShimCache), which preserve evidence of programs that were executed even when they are no longer present on disk.
  5. Other file system artefacts: entries in the MFT, the USN journal, shortcuts (LNK), unallocated space and so on, which are beyond the main focus of this document but can complement the analysis.

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:

3. Identifying software from the graphical interface

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.

3.1. Settings - Apps (Windows 10/11)

Typical path:

  1. Open the Start menu and click on the Settings icon (gear).
  2. Select Apps.
  3. In Windows 11, choose Installed apps; in Windows 10, Apps and features.

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 ChromeGoogle LLC
Microsoft EdgeMicrosoft Corporation
Microsoft OneDriveMicrosoft Corporation
Mozilla FirefoxMozilla
NotepadMicrosoft Corporation
PaintMicrosoft Corporation
VLC media playerVideoLAN

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.

3.2. Control Panel - Programs and Features

Although less visible in recent versions, the classic Control Panel still exists and offers a similar view:

  1. In the search box, type Control Panel and open it.
  2. Go to Programs > Programs and Features.

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
DropboxDropbox Technologies LLC05/01/2024
Google ChromeGoogle LLC09/04/2024
Microsoft EdgeMicrosoft Corporation16/03/2024
Microsoft ExcelMicrosoft Corporation26/12/2023
Microsoft OneDriveMicrosoft Corporation21/02/2024
Microsoft WordMicrosoft Corporation05/01/2024
Mozilla FirefoxMozilla09/04/2024
SkypeSkype23/04/2024
VLC media playerVideoLAN09/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.

4. Windows Registry Analysis

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.

4.1. Uninstall Keys (HKLM and HKCU)

The main locations where Windows and many applications store information about installed software are:

These paths are widely documented in technical literature and forensic guides on installed programs.

Basic manual inspection procedure:

  1. Run regedit.exe with administrative privileges.
  2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
  3. Each subkey represents an installed product. The most relevant values typically include:
    • DisplayName: product name;
    • DisplayVersion: reported version;
    • Publisher: vendor;
    • InstallDate: installation date (often in YYYYMMDD format);
    • UninstallString: command or path used to uninstall the product.

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.

4.2. Installation and uninstallation times

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.

5. Installation and uninstallation history in event logs

Windows event logs are another key source for reconstructing the installation and uninstallation history, particularly for software that uses the Windows Installer (MSI) service.

5.1. MsiInstaller events in Event Viewer

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.

Basic GUI procedure:

  1. Open the Start menu and type Event Viewer.
  2. In the left pane, navigate to Windows Logs > Application.
  3. In the right pane, click Filter Current Log.
  4. In the dialog box, set Event sources to MsiInstaller and optionally specify event IDs such as 11707 and 11724.
  5. Apply the filter.

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.

5.2. Export and temporal correlation

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.

6. Execution artefacts that survive uninstallation

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.

6.1. Prefetch: evidence of executed programs

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.pf22/04/2024 12:17 p.m.PF File
CHROME.EXE-7B0683C.pf23/04/2024 12:17 p.m.PF File
EXPLORER.EXE-28F6CF77.pf22/04/2024 12:17 p.m.PF File
FIREFOX.EXE-11BE7758.pf22/04/2024 12:17 p.m.PF File
NOTEPAD.EXE-9D56FCAF.pf22/04/2024 12:17 p.m.PF File
SERVICES.EXE-32D1A1BD.pf22/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.

6.2. AmCache and ShimCache: compatibility and activity caches

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.

Note: AmCache and ShimCache are especially valuable because they often retain references to programs that have been deleted from the file system, allow executables to be linked with approximate execution and installation times, and lend themselves to automated analysis using specific forensic tools.

6.3. Other file system artefacts

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.

7. Detection of "last-minute" uninstallation

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.

7.1. Temporal correlation with event logs

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:

7.2. Coherence between execution artefacts and current system state

Another strategy is to compare the current state (programs actually present on disk and listed in Uninstall) with the historical execution artefacts:

7.3. Registry residues and cleanup patterns

Often, hasty uninstallations leave partial traces in the registry:

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.

8. Practical recommendations for forensic reports

When preparing a forensic report on potentially uninstalled software, it is advisable to:

  1. Document multiple sources: Do not rely on a single artefact. Cross-reference registry keys, event logs, Prefetch, AmCache and ShimCache.
  2. Construct timelines: Present the evidence chronologically, correlating system events with procedural milestones.
  3. Include screenshots and exports: Capture and export registry keys, event logs and relevant file listings to support your findings.
  4. Explain limitations: Clearly state which artefacts were not available and why (e.g., Prefetch disabled, event logs cleared).
  5. Use forensic tools: Employ specialized software to extract LastWrite times, parse AmCache and ShimCache, and analyze unallocated space.
  6. Maintain chain of custody: Document all tools, versions and procedures used to ensure reproducibility and admissibility in court.

9. Conclusions

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.

10. References and further reading

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 —