STATUS_CHECKOUT_REQUIRED 0XC0000902 — file locked by VSS

You're trying to save a file and Windows stops you cold with STATUS_CHECKOUT_REQUIRED (0XC0000902)

I know how annoying this is — you're in the middle of something, hit Ctrl+S, and get this cryptic error instead of a saved file. Let's get you past it.

The fast fix

Open the file's parent folder in Explorer. Look for a folder named VSS or a file with a .scc extension (like myfile.txt.scc). If you see it, the file is checked out in Microsoft Visual SourceSafe (VSS) or a legacy source control system. Delete or rename that .scc file. Then try saving again.

If that doesn't work, the file itself is locked. You have two options:

1. Undo the checkout: In VSS, right-click the file and select Undo Check Out. This releases the write lock.
   If you don't have VSS installed, you can skip this — the real lock is in the file system, not VSS itself.
2. Copy the file elsewhere: Copy the file to a temp folder (like Desktop\temp\), edit the copy, and then either move it back (overwriting the original) or just work from the copy.

The trick is: once you copy it, Windows doesn't try to enforce VSS locks on the copy. You can save freely there.

What's actually happening here

The error code 0XC0000902 maps to STATUS_CHECKOUT_REQUIRED in NT kernel status codes. Microsoft originally built this into the I/O manager to support VSS's checkout model. When a file is checked out, VSS sets an extended attribute on the file saying "this file is locked — only the user who checked it out can write to it."

But here's the thing: that lock isn't enforced by VSS itself (the app). It's enforced by the Windows kernel's file system filter. When any process tries to write to a file with that attribute set, the kernel returns STATUS_CHECKOUT_REQUIRED — even if VSS isn't even running. That's why deleting the .scc control file works: it removes the extended attribute, and the kernel stops blocking writes.

The reason step 2 works (copying the file) is that copying creates a brand new file with no VSS extended attributes. The kernel sees a clean file and allows writes.

Less common variations of the same issue

Sometimes this error pops up from other source control systems that mimic VSS's file-locking behavior:

• Team Foundation Server (TFS) in old workspace mode: TFS 2010 and earlier used a similar checkout-on-edit model. If you see 0XC0000902 in a TFS workspace, the fix is to change the workspace to Local mode (in Visual Studio: File → Source Control → Advanced → Workspaces → Edit → set to Local).
• Perforce with exclusive checkout: Perforce can set a similar lock via the p4 protect command on a file type of +l (exclusive lock). The error may show as STATUS_CHECKOUT_REQUIRED if the Perforce proxy filter is installed. Run p4 revert -k filename to unlock without losing changes.
• Windows File Protection (WFP): In rare cases, Windows File Protection on system files like notepad.exe can trigger this error. The fix is to take ownership of the file first: takeown /f C:\Windows\System32\filename.exe then icacls C:\Windows\System32\filename.exe /grant Administrators:F. But don't touch system files unless you know what you're doing.
• Custom file locking via fsutil: Someone may have manually set a checkout flag using fsutil file setvaliddata or fsutil resource set. Run fsutil resource info C:\path\to\file to check. If a checkout flag is set, you can clear it with fsutil file setvaliddata C:\path\to\file 0 — but this is dangerous and can corrupt the file's data integrity.

If none of those fit, open a command prompt as admin and run reg query HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v NtfsDisable8dot3NameCreation. A value of 0 means 8.3 names are enabled, which can confuse some old source control systems. Set it to 1 (reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v NtfsDisable8dot3NameCreation /t REG_DWORD /d 1 /f) and reboot. This is a long shot but I've seen it fix the error in legacy environments.

Prevention for next time

The real prevention is to stop using VSS. It's been deprecated since 2010. Migrate to Git (with git lfs for binary files) or at least to TFS in Local workspace mode (which doesn't use checkout locks).

If you're stuck on VSS because of legacy apps, set your editor to open files as read-only by default. In Notepad++, go to Settings → Preferences → New Document → Default encoding → UTF-8 and also set File Status Auto-Detection to Enable. That way your editor won't try to write to a locked file until you explicitly say "save." You'll get a gentle warning instead of the error.

Also, create a local backup folder outside the VSS-controlled directory. Work on a copy there, then check in the final result to VSS. That avoids ever hitting this error because you're never writing to a locked file — you're only writing to a copy, and then you check the original in/out deliberately.

If you're an admin, you can disable the VSS file system filter entirely by stopping the VSSVC.exe service (run net stop VSS as admin) and setting its startup type to Disabled. This removes the kernel-level lock check for all files, but it also means VSS won't work at all until you start it again.