Enabling Hidden Windows 11 Features with ViVeTool Without Breaking Anything

Windows 11 ships with code for features that are compiled but switched off. ViVeTool is the utility that flips those switches, and most guides make it look like a one-liner. In practice the /enable command is the easy part — the work is in the three checks around it: does your build actually contain the feature, does the ID match your build, and can you get back to where you started?

This is the workflow I use. Budget 20–30 minutes, including a reboot and a restore-point check. It's an intermediate task; if you've never opened an elevated PowerShell window, read through once before running anything.

A feature flag is a switch, not a delivery truck

A flag is a hidden on/off bit inside Windows. ViVeTool changes the bit. It cannot add code that isn't there.

That single sentence explains most of the frustration people hit. If the feature code hasn't landed in your build, /enable may still print a success message while nothing observable changes. Feature IDs are build-specific, so an ID copied from a blog post about a different build is not a shortcut — it's a dead end. Treat every ID as unverified until /query confirms it exists on your machine.

Prep work that actually matters

Gather these before you start:

• Windows 11 with a known build number (you'll record it in the next step).
• Administrator rights — ViVeTool writes system configuration and normally wants an elevated prompt.
• A ViVeTool release matching your CPU architecture, extracted to a local folder, e.g. C:\Users\<you>\Downloads\ViVeTool\ViVeTool.exe.
• The target feature ID, taken from the release notes or a trusted tracker for your exact build. I'll use <feature-id> as a placeholder throughout.
• System Protection enabled, or permission to create a restore point.
• Free space for the archive, the extracted files, and the checkpoint. Get-PSDrive C tells you.

Create the checkpoint first:

Enable-ComputerRestore -Drive "C:\"
Checkpoint-Computer -Description "Before ViVeTool" -RestorePointType MODIFY_SETTINGS
Get-ComputerRestorePoint | Select-Object -Last 1

The last command should come back with a recent entry reading Description : Before ViVeTool. If System Protection is disabled by policy, the checkpoint command fails — stop there and fix that first. Running ViVeTool without a rollback point is the one mistake that turns a 20-minute experiment into an afternoon.

If the feature depends on a Windows update you haven't installed yet, install the update before doing anything else.

Step 1: Record the build, architecture, and rollback baseline

Open an administrator PowerShell window and save the OS build, architecture, and your feature-ID worksheet.

$baseline = "$env:USERPROFILE\Desktop\vive-baseline.txt"
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture | Tee-Object -FilePath $baseline
[System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture | Tee-Object -FilePath $baseline -Append

Expected shape of the output:

WindowsProductName : Windows 11 ...
WindowsVersion     : <version>
OsBuildNumber      : <build-number>
OsArchitecture     : <architecture>

The architecture line decides which ViVeTool build you download: X64 means x64, Arm64 means ARM64. Don't mix them.

Then write a small worksheet so the experiment stays reproducible:

Before continuing, confirm: build saved to vive-baseline.txt, architecture checked, feature ID recorded with its source, restore point visible in Get-ComputerRestorePoint, and only one ID in play.

Step 2: Stage ViVeTool and enable exactly one flag

Extract, hash, query, enable — in that order.

$work = "$env:USERPROFILE\Downloads\ViVeTool"
New-Item -ItemType Directory -Path $work -Force
Expand-Archive -LiteralPath "$env:USERPROFILE\Downloads\ViVeTool.zip" -DestinationPath $work -Force
Set-Location $work
Get-ChildItem
Get-FileHash .\ViVeTool.exe -Algorithm SHA256

Compare the SHA256 value against the one published with your ViVeTool release. If they differ, delete the folder and download again — don't reason with it.

Now elevate:

Start-Process powershell -Verb RunAs

In the elevated window, query before you change anything:

Set-Location "$env:USERPROFILE\Downloads\ViVeTool"
.\ViVeTool.exe /query /id:<feature-id>
.\ViVeTool.exe /query > "$env:USERPROFILE\Desktop\vive-before.txt"
.\ViVeTool.exe /enable /id:<feature-id>

If /query /id:<feature-id> returns no matching feature, stop. The ID is wrong for this build, and enabling it will only produce noise. Saving the full /query dump to the Desktop gives you a before/after comparison later.

A successful enable prints something like Successfully set feature configuration(s). Then reboot so the flag is loaded at startup:

Restart-Computer

Why one ID at a time? Attribution. Enable five flags, the UI breaks, and you have no way to tell which one did it.

Step 3: Verify twice — state, then behavior

After the reboot, query the same ID again and then look at the UI or app the flag is supposed to change.

Set-Location "$env:USERPROFILE\Downloads\ViVeTool"
.\ViVeTool.exe /query /id:<feature-id> | Select-String -Pattern "Enabled|State|Feature"

ViVeTool state and visible behavior are two separate checks, and this is where most write-ups quietly skip the failure case. A flag can report enabled while the UI stays identical, because a dependency, an app version, or a server-side experiment is still missing.

If the feature doesn't show up and you don't need it, roll back right away instead of enabling more IDs and hoping:

.\ViVeTool.exe /disable /id:<feature-id>
Restart-Computer

After the reboot, /query /id:<feature-id> should show the feature as disabled or inactive. If it doesn't, restore the checkpoint from Step 1.

Two errors you will probably hit

The term 'ViVeTool.exe' is not recognized... — PowerShell won't run executables from the current directory unless you prefix them with .\, or you're simply in the wrong folder. Fix both at once:

Set-Location "$env:USERPROFILE\Downloads\ViVeTool"
.\ViVeTool.exe /query

Access is denied — the window isn't elevated, so ViVeTool can't write the feature configuration. Confirm elevation before retrying:

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

True means you're good; False means start a new administrator window.

What I take away

ViVeTool is a switch-flipper, not a feature installer. The ID has to exist in your build, the flag state has to be checked separately from the UI, and every experiment needs a checkpoint behind it plus a one-command way out. Record the build, change one ID, reboot, verify twice, and keep the result only if both checks agree.

This article was originally published on AI Release — https://ai-release.org. More practical Windows and tooling guides land regularly on the channel: https://t.me/ai_release1.