Auditing Registry Writes Before Deployment with pkgprobe

01 Where the Real Footprint Lives

When an installer runs, the files it copies to Program Files are only half the story. The registry writes are where the installer establishes persistence — startup behavior, service definitions, protocol handlers, file associations, and the upgrade detection logic that determines whether future versions deploy correctly.

These are the hives that matter most for pre-deployment review:

If you don't know which of these paths an installer writes to before deployment, you're gambling — especially in regulated environments where unexpected persistence or service creation triggers immediate EDR and compliance scrutiny.

02 What pkgprobe Extracts

For MSI installers, pkgprobe directly inspects the installer's Registry table, ServiceInstall table, and Class table — producing a complete pre-execution map of every key that will be written. No sandbox. No execution. The footprint, before the installer runs.

The output gives you exactly what you need for a pre-deployment review:

from pkgprobe import analyze_msi

plan = analyze_msi("VendorApp.msi")

# Full registry footprint before execution
for reg in plan.registry_writes:
    print(reg.hive, reg.path, reg.value_name)

# Service definitions
for svc in plan.service_installs:
    print(svc.name, svc.start_type, svc.account)

# COM registrations
for com in plan.com_registrations:
    print(com.clsid, com.prog_id)

Now you can ask the right questions before deployment: Why is this app creating a Run key? Does this service need to auto-start? Is this overwriting an existing COM registration that another app depends on?

03 Red Flags to Watch For

Not all registry writes are equal. These four categories warrant direct review before any installer goes to production:

04 Pre-Deployment Registry Review Workflow

The goal is to move registry discovery from post-deployment troubleshooting to pre-deployment review. The shift is simple:

05 Enforcing Policy in CI/CD

Registry auditing doesn't have to be a manual step. You can encode your org's policy directly into your pipeline and block installers that violate it automatically — before they ever reach a staging environment.

from pkgprobe import analyze_msi

plan = analyze_msi("app.msi")

for reg in plan.registry_writes:

    # Block any user-level startup persistence
    if "CurrentVersion\\Run" in reg.path:
        raise Exception(
            f"Blocked: user-level persistence at {reg.path}"
        )

    # Flag unexpected protocol handlers
    if reg.hive == "HKCR" and "shell\\open\\command" in reg.path:
        raise Exception(
            f"Blocked: unexpected shell handler at {reg.path}"
        )

for svc in plan.service_installs:

    # Block services running as LocalSystem
    if svc.account == "LocalSystem":
        raise Exception(
            f"Blocked: service '{svc.name}' runs as LocalSystem"
        )

print("Registry policy checks passed.")

06 Real-World Scenario: The Silent Vendor Update

This scenario plays out regularly in enterprise IT. A vendor releases a routine MSI update — same product, incremented version. The packaging team tests installation. Exit code 0. Moves to production.