Kill It With Fire
Force uninstall a Windows app that won’t die, completely. It runs the app’s own uninstaller silently, then cleans up what it left behind: services, drivers, credential providers, network components, scheduled tasks and registry. Or it skips the uninstaller when that’s the problem.
Scans first and changes nothing until you say so. Backs up everything it touches. Restore puts a run back.Read this first
This removes software. Any software, live or broken. That’s the whole point, and it’s also why it runs as administrator and can do real damage if you don’t know what you’re doing. So: scan first, read the plan, try it on a VM before your fleet, and leave the backup on. It refuses Microsoft software, security agents and Windows itself, and tells you why.
Every desktop engineer has a list of apps that won’t die. The VPN client whose network driver outlives the software itself. The SSO agent that ships a credential provider you can finally get rid of. Kill It With Fire is what years of cleaning those up by hand, across a fleet of about 30,000 endpoints, turned into.
1Download it and check the signature
That’s the latest release on GitHub, where the source, the README and every release live. It’s Authenticode-signed by Vitko Software, LLC with a timestamp. Check it before you run anything:
Get-AuthenticodeSignature .\KillItWithFire.ps1 | Format-List Status, SignerCertificate Status should read Valid. If the file was changed after it was signed, it reads
HashMismatch, and you shouldn’t run it.
2Scan, then choose how far to go
From an elevated PowerShell prompt. With no arguments it opens a window: pick the app, Scan it, choose what to clean, then Clean up. The window shows the matching command line for every choice.
powershell -ExecutionPolicy RemoteSigned -File .\KillItWithFire.ps1Or from the command line, which is what you push from Intune, PDQ or an RMM:
.\KillItWithFire.ps1 -List # installed apps
.\KillItWithFire.ps1 -Name "Notepad++ (64-bit x64)" # scan only: the plan and the evidence
.\KillItWithFire.ps1 -Name "Notepad++ (64-bit x64)" -Level 3 -Force # the proper way
.\KillItWithFire.ps1 -Name "Notepad++ (64-bit x64)" -KillIt -Force # the hard way
.\KillItWithFire.ps1 -Restore 20260926-093000-1a2b3c -Force # put a run back| Level | What it does |
|---|---|
| 0 | Scan only. Writes the plan and a report. Changes nothing. The default. |
| 1 | Uninstall. Runs the app’s own uninstaller once, silently. KILL IT skips it. |
| 2 | Registration cleanup. Removes the uninstall entry and the Windows Installer registration, so the app can install again. Files aren’t touched. |
| 3 | Full scrub. Unhooks the app from Windows, then moves its files to a quarantine on the same drive. |
How it decides what belongs to the app
Identity first, never name first. It starts from the app’s own registration: its uninstall entry, its Windows Installer product and components, and the files and registry values its MSI says it owns. From there it finds what points at those folders and files: services, drivers, scheduled tasks, Run keys, COM classes, shell extensions, file associations, credential providers, network providers, firewall rules and shortcuts. Each item in the plan says why it’s there.
A tie that’s only a vendor name, a signer, or one MSI’s claim on a Windows file is marked uncertain and left alone unless you opt in. A folder another installed product also uses is shared: only the app’s own files inside it go. A driver that also serves real hardware stays.
The order matters
A full scrub unhooks things in a fixed order, so a run that stops part way never leaves a machine worse
than it found it. The built-in password sign-in is turned back on before an SSO agent’s credential
provider goes, so nobody is locked out. Device filters go before the driver they name, because a filter
pointing at a deleted driver stops every device in that class at the next boot. Services stop before
their drivers, and files go last, once nothing loads them. A file that’s in use moves at the next
boot instead, and -Resume confirms it happened.
Tested on the apps that are hard to remove
Every change runs against a lab of Hyper-V VMs, including the ones that make this hard: Imprivata (a credential provider wrapped around every sign-in tile), FortiClient VPN (network components and software-created adapters that come back on the next boot), VirtualBox and Npcap (kernel drivers and network filters), plus a couple dozen everyday apps. For those four, the credential providers, the network stack and the driver store were compared after removal with a snapshot taken before the app went on, and matched. Unit tests and the lab scenarios that don’t need a reboot also run on every change, on a throwaway GitHub runner.
It still isn’t perfect. If it gets something wrong, the backup is there, and an issue on GitHub is the fastest way to get it fixed.
Only need the silent uninstall command?
If the app’s own uninstaller works and you just need it to run quietly, you don’t need any of this. SwitchHunt reads an installer and gives you its silent install and uninstall commands.
Questions
Is it safe to run?
It runs as administrator and removes software, so it can do real damage if you point it at the wrong thing. What it does to limit that: a scan changes nothing and shows every item with the evidence that ties it to the app; weak matches are left alone unless you opt in; everything it changes is backed up first; and Restore puts a run back. Scan first, read the plan, try it on a VM before your fleet, and leave the backup on.
What is the difference between the proper way and KILL IT?
The proper way (the default) runs the app’s own uninstaller silently first, then cleans up what it left behind. KILL IT skips the uninstaller and goes straight to the cleanup, for when the uninstaller is the problem: it hangs, it is broken, or it waits for a click nobody is there to give. Both are backed up and both can be restored.
Can I run it from Intune, PDQ or an RMM?
Yes. Run it as SYSTEM with -Force and it runs without asking. Exit codes are 0 (done), 3010 (done, reboot to finish, then -Resume), 1 (stopped part way, the rest can be restored), 2 (refused), 3 (bad input or not elevated). Without -Force it prints the plan and waits for you to type YES.
Will it remove my antivirus or EDR?
No. Security products are refused, and the report names the vendor’s own removal tool (CrowdStrike’s CsUninstallTool with the maintenance token, for example). Tamper protection makes a generic removal of those unpredictable, so that conversation belongs with your vendor.
What will it never touch?
Microsoft software (by publisher, or by who signed the app’s own executables), security products, Windows folders, users’ Desktop, Documents, Downloads and OneDrive, and SharedDLLs reference counts. A folder another installed product also uses is treated as shared: only the app’s own files inside it go, and the folder stays.
Why a script instead of an executable?
Because you can read it before you run it, which is the right instinct for anything that removes software as administrator. It is Authenticode-signed and timestamped, so Get-AuthenticodeSignature tells you who published it and whether a single byte has changed.
Does it upload anything?
No. It writes its plan, report, log and backups to a folder under ProgramData on the machine it ran on, readable by SYSTEM and Administrators only. Nothing leaves the machine.
Can I lock down what my techs can do with it?
Yes, with Group Policy or Intune: values under HKLM\SOFTWARE\Policies\KillItWithFire set the highest level anyone can run, require a backup and a log, fix where the log goes, and forbid removing user data. The engine enforces them, and the window shows them greyed out.
Open source
Kill It With Fire is MIT-licensed at github.com/deadarcher/kill-it-with-fire. One PowerShell file, Windows PowerShell 5.1 or PowerShell 7, no dependencies. Read it before you run it.