Dev Drive Setup

Create a Windows 11 Dev Drive in one command — a ReFS volume where Microsoft Defender scans asynchronously instead of blocking every file operation. Speeds up the heavy small-file I/O of git, node_modules, NuGet restore and bin/obj builds.

The drive is VHD-backed (a single .vhdx file), so it needs no repartitioning and is fully reversible — dismount the VHD and delete the file to reclaim the space.

---

Contents

• Why
• Measured results
• Requirements
• Quick start
• Full setup guide
• Scripts
• Is it safe?
• Remove it later
• How it works
• License

Why

On a normal NTFS drive, Defender scans every file synchronously on access — so npm install, git checkout and rebuilding bin/obj pay an antivirus tax on thousands of tiny files. A Dev Drive is ReFS and Defender runs in asynchronous performance mode: file operations are no longer blocked waiting for a scan, while the volume stays protected.

Measured results

Benchmarked with the included Benchmark-DevDrive.ps1 (8,000 × 2 KB files, average of 2 timed runs, first run discarded as warm-up). Both drives sit on the same physical NVMe — the Dev Drive is just a VHD file on C: — so the only variable is the Defender scan mode.

Exact figures

Operation	C: (NTFS)	Dev Drive (ReFS)	Delta
Write / create	12,154 ms	8,370 ms	−31%
Read	4,790 ms	2,524 ms	−47%
Delete	2,957 ms	1,134 ms	−62%
Total	19,901 ms	12,028 ms	−39.6%

▶ Open the live interactive chart — animated on scroll, hover the bars for exact timings.

Numbers vary with machine load and hardware. Run the benchmark on your own machine — a native (non-VHD) Dev Drive partition typically shows an even larger gap.

Requirements

• Windows 11, build 22621.2338 or newer (22H2 with the Sept 2023 servicing update — run Windows Update if unsure)
• Windows 11 Pro / Enterprise / Business for the Hyper-V VHD cmdlets these scripts use (Dev Drive itself works on all SKUs — on Home, create it via Settings → System → Storage → Disks & volumes instead)
• Free space on C: ≥ chosen size + 5 GB (minimum Dev Drive size is 50 GB; the default 60 GB needs ~65 GB free)
• 16 GB RAM recommended (8 GB minimum) — ReFS uses slightly more memory than NTFS
• Admin rights — the scripts self-elevate via a UAC prompt, so just run them normally

Quick start

# 1. Clone
git clone https://github.com/PaloMiklo/win11-dev-drive-setup.git
cd win11-dev-drive-setup

# 2. Create the Dev Drive (defaults: 60 GB at D:). Approves via a UAC prompt.
powershell -ExecutionPolicy Bypass -File .\Create-DevDrive.ps1

# 3. (optional) Make it survive reboots
powershell -ExecutionPolicy Bypass -File .\Register-DevDriveAutoMount.ps1

Or right-click Create-DevDrive.ps1 → Run with PowerShell. The script prints its plan and waits for Y/N before changing anything. On success fsutil reports "This is a trusted developer volume."

Scripts

Script	What it does
Create-DevDrive.ps1	Creates the VHD-backed ReFS Dev Drive. Five guard checks + Y/N confirm before any change.
Register-DevDriveAutoMount.ps1	Registers a logon scheduled task so the VHD re-mounts after every reboot. -Remove to undo.
Prove-DevDriveDefender.ps1	Proves via fsutil devdrv query that the drive is a trusted developer volume protected by Defender's async filter.
Benchmark-DevDrive.ps1	Measures small-file write/read/delete on the Dev Drive vs C: and writes a results file.

Create-DevDrive.ps1 parameters

Parameter	Default	Meaning
-SizeGB	60	Max size of the dynamic VHD (GB)
-PreferredLetter	D	Drive letter; falls back if taken
-VhdPath	C:\DevDrives\DevDrive.vhdx	Where the .vhdx file lives

.\Create-DevDrive.ps1 -SizeGB 80 -PreferredLetter E

Full setup guide

The complete path from zero to a fully working Dev Drive (replace D: with your letter):

1. Create the drive

.\Create-DevDrive.ps1                    # 60 GB at D: — prints its plan, asks Y/N

2. Make it survive reboots (a VHD is not re-attached automatically)

.\Register-DevDriveAutoMount.ps1         # logon scheduled task that mounts the VHD

3. Verify it — trust + async Defender, then measure the gain on your hardware

.\Prove-DevDriveDefender.ps1             # fsutil proof: trusted volume, WdFilter async
.\Benchmark-DevDrive.ps1                 # C: vs Dev Drive on 8,000 small files

4. Point package caches at it so the I/O-heavy work lands on the fast volume. Pick the ones you use:

Ecosystem	How
npm	npm config set cache D:\caches\npm
NuGet	[Environment]::SetEnvironmentVariable("NUGET_PACKAGES", "D:\caches\nuget", "User")
pip	[Environment]::SetEnvironmentVariable("PIP_CACHE_DIR", "D:\caches\pip", "User")
Cargo	[Environment]::SetEnvironmentVariable("CARGO_HOME", "D:\caches\cargo", "User")
Maven	[Environment]::SetEnvironmentVariable("MAVEN_OPTS", "-Dmaven.repo.local=D:\caches\maven", "User")
Gradle	[Environment]::SetEnvironmentVariable("GRADLE_USER_HOME", "D:\caches\gradle", "User")

Restart open terminals (or reboot) so the new environment variables apply.

5. Move your code there — clone repositories onto the drive (clone, don't copy — keeps git metadata and line endings clean):

cd D:\ ; git clone <your-repo>

What stays on C:: your IDE, SDKs and tools (Visual Studio, Node, .NET, …). Only the workload files — repos, caches, build output — belong on the Dev Drive.

Note: don't move the .vhdx to another machine and keep using it there — the Dev Drive trust designation is per-machine and doesn't travel with the file.

Is it safe?

Yes — it is non-destructive by design:

• Only ever creates a new .vhdx and formats the fresh volume inside it. It never shrinks, deletes, repartitions or formats any existing disk.
• Formats a captured partition object, never a bare drive letter — an existing volume physically cannot be the target.
• Six guard checks abort before any change: not elevated · size below the 50 GB minimum · unsupported Windows build · VHD cmdlets missing · VHD file already exists · not enough free space.
• Prints its plan and waits for Y/N before making the first change.

Remove it later

Also non-destructive to your system:

.\Register-DevDriveAutoMount.ps1 -Remove             # remove the auto-mount task (if set)
Dismount-VHD -Path "C:\DevDrives\DevDrive.vhdx"      # detach, keep the data
Remove-Item  "C:\DevDrives\DevDrive.vhdx"            # delete the file, reclaim the space

Always dismount before deleting the file. To undo the cache redirects:

npm config delete cache
[Environment]::SetEnvironmentVariable("NUGET_PACKAGES", $null, "User")

How it works

The Dev Drive is a dynamically-expanding VHDX file mounted as a ReFS volume and marked as a trusted developer volume (Format-Volume -DevDrive). Windows then attaches Defender's WdFilter in asynchronous mode: the volume is still scanned, but file operations aren't blocked waiting for the scan — which is exactly where NTFS loses time on small-file dev churn. See Prove-DevDriveDefender.ps1 for the proof and Benchmark-DevDrive.ps1 for the numbers.

Optional local helper — "Run as Admin" shortcuts. The scripts already self-elevate, so you don't need shortcuts. If you want desktop shortcuts anyway, generate them locally (they are git-ignored so your personal path is never committed):

$s = (New-Object -ComObject WScript.Shell).CreateShortcut("$PWD\Create-DevDrive (Run as Admin).lnk")
$s.TargetPath = "powershell.exe"
$s.Arguments  = "-NoProfile -ExecutionPolicy Bypass -File `"$PWD\Create-DevDrive.ps1`""
$s.Save()

License

MIT — do whatever you want, no warranty.