I built a PowerShell-based tool with help from an LLM and would appreciate a serious code review. The goal is to disable Microsoft Defender without deleting files from WinSxS, so Windows updates continue to work and the system can be restored later.
The tool has a single entry point that performs preflight checks, saves a full system snapshot to defender-backup.json, configures a RunOnce action for Safe Mode, reboots into Safe Mode for the second stage, and then reboots back into normal mode. Restoration uses the saved backup rather than hardcoded defaults.
To work with TrustedInstaller-protected registry keys, it compiles a small C# helper in memory with Add-Type for registry ownership and token-related operations. It also has a fallback input function that tries RawUI.ReadKey first and uses Read-Host when running without an interactive console.
The main things I'm unsure about are whether in-memory C# is a reasonable approach or whether there is a cleaner PowerShell-only option, whether system-level failures should be logged as partial and allowed to continue or should stop the process immediately, and whether there are compatibility problems on Windows 10 or Windows 11 Pro and Home. I have only tested it on Windows 11 IoT Enterprise 25H2. The intended use cases include compatibility with third-party endpoint products and reducing unwanted resource usage or false positives, but I'm especially interested in feedback about safety, rollback reliability, permissions, and failure handling.
3 Answers
Before getting into implementation details, the biggest review question is why Defender needs to be disabled at all. Some endpoint products have documented compatibility requirements, but for personal systems it may be safer to use Defender exclusions, passive mode, or vendor-supported configuration instead of broadly changing protected registry settings. A mistake during Safe Mode or rollback could leave the machine without effective protection.
For personal use, my motivation is mostly avoiding false positives and background resource usage. I agree that the script should make the risk and supported alternatives very clear.
Using Add-Type is not automatically a problem, but it increases complexity and makes compatibility and review harder. More importantly, changing ownership and permissions on protected registry keys is a high-impact operation. Keep the native helper as small as possible, validate architecture and PowerShell version up front, and avoid assuming that registry paths, service behavior, Safe Mode handling, or Defender policy locations are identical across Windows editions.
I’d test in disposable virtual machines for every target edition, including interrupted reboots, missing backup files, corrupted backups, access-denied errors, and a restore performed after only the first stage completed. Also consider code signing, an explicit elevation check, tamper-resistant backup handling, and a clear confirmation step before making security software changes.
For a system-level script, continuing after a partial failure is risky. If ownership changes, registry writes, backup creation, or reboot staging fails, I’d stop immediately, record the exact operation and exception, and avoid moving to the next stage. A partial state can be worse than no change at all. Add verification after every write and make the restore path independently usable, including when the main workflow does not complete.
A structured transaction-style log would help: record the original value, attempted operation, result, and whether the value was verified afterward. That is much more useful than a generic PARTIAL line.
There are legitimate cases where a third-party endpoint product requires Defender to be disabled, especially on older Windows Server releases. That should still be handled through the vendor’s documented deployment process where possible.