How to Fix “Could Not Open Fast-String Registry” in Android Studio

The could not open fast-string registry error shows up during a Gradle build or sync in Android Studio, usually right after you’ve done something that touched the JVM, the Gradle daemon, or your disk in a way Gradle didn’t expect. I ran into this one on a project that had been building fine for weeks, and it took me longer than I’d like to admit to figure out what was actually going on.

Quick Answer

If you’re in a hurry, try these in order:

• Stop all Gradle daemons and delete the daemon registry files
• Clear the .gradle folder in your project (not your global one) and re-sync
• Check that your JDK path hasn’t changed or gone stale after an update
• Make sure no antivirus or backup tool is locking files inside .gradle
• If none of that works, nuke the global Gradle cache under ~/.gradle/caches

That last one is the nuclear option. Don’t reach for it first.

Why It Fails

This error is really a symptom, not a root cause. It means Gradle (or the JVM running underneath it) tried to open or lock an internal registry file used for interned strings and metadata sharing, and something got in the way. From what I’ve seen, it comes down to a handful of repeat offenders.

1. A corrupted or half-written registry file. Gradle daemons keep track of internal state in cache files on disk. If a daemon gets killed mid-write — a crash, a forced shutdown, your laptop dying because you forgot to plug it in — that file can end up in a broken state. The next daemon that tries to open it chokes.

2. File locking conflicts. Windows is especially bad about this. Antivirus software, OneDrive sync, or a backup tool scanning your .gradle directory at the exact moment a daemon tries to write to its registry file will produce exactly this kind of error. It’s not consistent, which is what makes it so annoying to diagnose.

3. JDK mismatch or stale JVM path. If you updated your JDK, switched between Android Studio’s bundled JDK and a system one, or your JAVA_HOME points somewhere that no longer exists, the daemon can fail in weird ways that surface as registry errors instead of a clean “JDK not found” message.

4. Disk or permission issues. Less common, but real — a full disk, a read-only .gradle folder after a permissions change, or a network drive that’s being flaky.

And honestly, sometimes it’s a stale daemon that’s just confused. Gradle daemons are supposed to make builds faster by staying alive between runs, but that same persistence means bad state can stick around longer than it should.

Technical Comparison Table

Step-by-Step Fixes

Step 1: Kill all Gradle daemons

Open a terminal in your project root and run:

./gradlew --stop

On Windows, use gradlew.bat --stop. This shuts down every running daemon cleanly instead of letting Android Studio try to reuse a broken one.

Step 2: Delete the daemon registry

Navigate to your Gradle user home — usually ~/.gradle on macOS/Linux or C:\Users\<you>\.gradle on Windows — and look inside the daemon folder. Delete the version-specific subfolder matching your current Gradle version (not the whole .gradle directory, just yet).

Step 3: Clear the project-level Gradle folder

Inside your project, delete the local .gradle folder (this is separate from the global one in your home directory). This forces Gradle to rebuild its configuration cache from scratch.

Step 4: Re-sync and watch the JDK setting

Go to File > Settings > Build, Execution, Deployment > Build Tools > Gradle, and check what JDK is selected. If it says something like “Use Project SDK” but that SDK was uninstalled or moved, that’s your answer right there.

Step 5: Check for file locks (Windows especially)

Temporarily disable real-time antivirus scanning, or add an exclusion for your Gradle folders. Same goes for OneDrive — if your project lives inside a synced OneDrive folder (please don’t do this), move it out.

Step 6: Full cache wipe (last resort)

If nothing above works, close Android Studio entirely and delete ~/.gradle/caches. This will force Gradle to redownload dependencies on the next sync, so expect it to take a while. Don’t do this on a slow connection right before a deadline.

What Actually Worked For Me

So my first instinct was that it was a corrupted download — that’s usually my go-to guess whenever Gradle throws something unfamiliar. I cleared the caches folder, waited through a 20-minute redownload, and got the exact same error. That was frustrating, not gonna lie.

Turned out the actual issue was my antivirus software (Windows Defender, with a third-party add-on my company IT had pushed) doing a real-time scan of the .gradle directory every time a daemon tried to write to it. I only figured this out because a coworker mentioned offhand that he’d had a similar registry-lock issue with a completely different Java tool, and it clicked. Added an exclusion for the .gradle folder, restarted the daemon, and it built clean on the first try.

Not 100% sure why it manifested as this specific error instead of a generic file-lock message, but that’s Gradle for you sometimes — the error message tells you where it failed, not really why.

Real-World Scenario

This tends to show up most often on shared or corporate laptops where IT has pushed some kind of managed antivirus or endpoint protection tool without much say from the developer. It also shows up after a JDK update rolls out through Android Studio’s own updater, which quietly changes the default Gradle JDK setting without telling you.

Advanced Fixes and Edge Cases

Enable Gradle debug logging. Run your build with --debug or at minimum --info to see exactly which file operation is failing right before the registry error appears:

./gradlew build --info

Scroll up from the error — the actual I/O exception underneath is usually a few lines above the “fast-string registry” message, and it’ll often name the exact file it couldn’t open.

Check Event Viewer on Windows. If antivirus or a security policy is blocking file access, Windows Event Viewer’s Application log sometimes shows a corresponding access-denied event around the same timestamp. It’s not always there, but when it is, it confirms the theory fast.

Watch for Secure Boot / BIOS-level virtualization changes. This is a stretch, but if you recently enabled hardware virtualization or changed BIOS settings for an emulator, and your antivirus tooling reacted by changing its scan behavior, that’s an edge case worth ruling out before you blame Gradle itself.

Multiple JDKs installed side by side. If you’ve got the Android Studio bundled JDK, a system JDK from Oracle or Adoptium, and maybe one installed by a different IDE, Gradle can occasionally pick up path ambiguity here. Run ./gradlew -v from the terminal to confirm which JVM Gradle is actually using versus what Android Studio shows in its settings — they don’t always match.

Prevention Tips

• Don’t force-kill Android Studio or your terminal while a Gradle build is running unless you have to
• Keep your project outside of cloud-sync folders like OneDrive, Dropbox, or Google Drive
• Add a permanent antivirus exclusion for your Gradle home and project .gradle folders
• After any JDK update, double-check your Gradle JDK setting instead of assuming it carried over
• Don’t run two Android Studio instances against the same project simultaneously

FAQ

Does deleting the Gradle cache delete my project files? No. It only deletes downloaded dependencies and daemon state — your source code is untouched.

Will this error come back after I fix it once? It can, especially if the underlying cause (antivirus, unstable JDK path) isn’t actually resolved and you just got lucky with a cache wipe.

Is this specific to Android Studio, or does it happen with plain Gradle too? It’s a Gradle-level issue, so yes, it can happen in any Gradle project, not just Android ones. Android Studio just surfaces it more often because of how frequently it triggers syncs.

Do I need to reinstall Android Studio to fix this? Almost never. This lives in Gradle’s cache and daemon layer, not in the IDE installation itself.

Why does restarting my computer sometimes fix it temporarily? A restart kills every lingering daemon process and file lock, so it clears the immediate symptom — but if the root cause is still there (bad AV config, broken JDK path), it’ll come back.

Is this related to low disk space? It can be, though it’s a less common cause than file locks or corrupted daemon state. Worth checking anyway since Gradle handles low disk space badly in general.

Editor’s Opinion

Yeah this one’s annoying mostly bc the error message tells you almost nothing useful on its own. Once you know it’s basically always a file lock or corrupted daemon thing it stops being scary. Just don’t jump straight to wiping your whole cache first, that costs you time and usually isn’t the actual problem anyway. Check what’s touching your .gradle folder first, save yourself the redownload.