You change one line in a build script, hit run, and get a wall of red. The error says “access denied” or “file in use” or points at a driver that has nothing to do with the code you touched. Two hours later you’re reinstalling the JDK because that felt like progress. It wasn’t.
Most broken local dev setups on Windows don’t break because of the IDE. They break underneath it: at the driver layer, the permission layer, or the antivirus layer. The frustrating part is these failures are quiet. Nothing crashes loudly. The build just won’t write to a folder it swears doesn’t exist, or the emulator crawls because the GPU driver is two years old, or a stale antivirus definition keeps quarantining a perfectly legitimate tool.
This is about the failure modes worth checking before you nuke your install. If you’ve already been through the “IDE won’t start after an update” checklist and the “two Java versions, one machine” dance, you’re ready for the layer below.
Permissions: the failures that don’t look like permissions
Windows will happily let you create a project in a folder you don’t actually have full control over. That’s where the weird ones live.
A classic: you extract a zip into C:\Program Files or directly under C:\. Explorer extracts it fine because your user account can write there in the moment. Then your build tool tries to write a temp file, or a node_modules directory gets created, and something down the chain needs elevation it never had. The installer you skipped “Run as administrator” on worked, but the tool it installed can’t update itself. Half the software writes where it should, half doesn’t.
The fix is boring and it works: don’t develop inside Program Files, Program Files (x86), or anywhere under the Windows directory. Keep projects under your user profile (C:\Users\yourname\dev is fine) or a dedicated drive. The moment you need admin rights to save a source file, something is structurally wrong with where that file lives.
The other permission trap is the read-only attribute that spreads. Copy files from a network share or a read-only source, and Windows can mark them read-only. Your editor saves, the tool can’t overwrite config, and you get a permission error that points at the wrong thing entirely. Right-click, Properties, clear Read-only, apply to contents.
Antivirus is a permissions problem wearing a costume
Real-time scanning locks files while it checks them. During a build, that means the compiler writes a binary, the scanner grabs it, and the next step in the pipeline tries to read a file that’s momentarily held. You get “file in use” on a file you just generated. You get builds that fail intermittently for no reason.
I’m not going to tell you to turn real-time protection off. That’s the answer bad guides give. The right move is to add exclusions for your development folders, the JDK or Node install, and the build output directories. One vendor’s setup guide points out that you can temporarily disable protection during an install if the vendor explicitly tells you to, then switch it back on. Note the word “temporarily.” An exclusion for C:\Users\yourname\dev is set once and stays useful. Disabling protection globally is how people get infected.
Drivers: where “it compiles but feels wrong” comes from
This is the category people skip because nothing errors. The app runs. It just runs badly.
Android emulators, GPU-accelerated browsers, anything using hardware acceleration, CUDA work, even scrolling in a resource-heavy IDE: all of it sits on top of the graphics driver. An outdated or generic Microsoft-provided driver (the one Windows installs by default when it has no vendor driver) gives you a working display and broken acceleration. The emulator boots, then stutters. The IDE is fine until you open something visual and it hangs.
Check the driver before you blame the tool. Device Manager, Display adapters, right-click your GPU, Properties, Driver tab. If the driver provider says Microsoft and the date is ancient, that’s your problem. Get the vendor driver from AMD, Nvidia, or Intel directly. Don’t rely on Windows Update alone to hand you the current one.
The other driver-adjacent culprit is the optional updates Windows hides from you. The advice to check Settings > Windows Update > Advanced options > Optional updates is real: driver and firmware updates live there, and they don’t install automatically. If you’ve been chasing a flaky USB-based embedded dev board or a serial adapter that keeps disappearing, that’s where the fix is often parked. Microsoft’s own performance guidance lists optional updates as a first check, and it’s a first check for a reason.
One more: chipset drivers. They don’t sound exciting and nobody installs them. Motherboard or laptop vendor, download page, chipset package. If your build machine randomly forgets its USB devices or drives drop off, this is worth twenty minutes.
Environment: the invisible variable that breaks everything
Environment variables are the quietest failure of all because half your tools read them and half don’t.
A PATH that’s grown to include three different toolchains means whatever resolves first wins. You think you’re running JDK 21 because that’s what your IDE points at, but your command line grabs JDK 8 from a stale PATH entry halfway down the list. The build passes in the IDE and fails in the terminal. That’s not a code bug. That’s two different environments with the same name.
The rule: pick one place where tools are installed, put exactly that on PATH, and stop appending. If you need a second toolchain, switch it per project or per shell session, not by stacking PATH entries and hoping.
And use where java (or where node, where python) to see what resolution actually looks like. The first line is what runs. If it’s not what you expected, you just found your bug.
The diagnostic order that saves time
When something breaks and you can’t tell why, work in this order instead of reinstalling.
- Confirm what actually runs.
wherefor every tool in the chain. Compare the version the tool reports to the version you think you installed. - Check where you’re writing. If the project lives under a protected folder, move it. If files are read-only, clear it. Don’t elevate; relocate.
- Read the error literally. “Access denied” is a permissions or lock problem. “File in use” is usually a scanner. “Not recognized as a command” is PATH. Stop guessing at the code layer.
- Check antivirus exclusions. If failures are intermittent and clustered around file writes, this is your first suspect, not your fifth.
- Check GPU and chipset drivers. Only after the above, because it’s slower. But if the symptom is “slow” or “crashy” rather than “error,” start here.
One practical note on installs: use the official installer, and run it as administrator when the software needs to write system files. That’s not paranoia, and many installers simply won’t configure themselves correctly otherwise. But “run as admin to install” is not “run as admin to use.” If your daily workflow needs elevation every time, the install went somewhere it shouldn’t have.
What you don’t need to touch
Half the “fix Windows for dev” advice floating around is about privacy settings, telemetry, Storage Sense, and cleanup. Those are fine and sometimes worth doing, but they rarely cause a build to fail. Disabling the advertising ID or switching off optional diagnostic data won’t fix a permissions error. If someone tells you to run Disk Cleanup to solve an access-denied build failure, keep looking.
The failures that actually cost you an afternoon live in three places: the folder you’re building in, the scanner watching it, and the driver sitting under the whole thing. Check those before you touch anything that says “reset.”