Your IDE updates itself overnight, you sit down with coffee, double-click the shortcut, and nothing happens. No splash screen. No error dialog. Just a cursor blink and silence. Or worse, a flash of a window that vanishes before you can read it.
I’ve hit this with IntelliJ IDEA, with VS Code, and once with a JetBrains Toolbox-managed install that decided its own runtime was gone. The instinct is to reinstall. Don’t, not yet. In most cases the update left something behind or removed something the launcher needs, and you can usually spot it in two minutes. Here’s the order I actually check things in.
First: Did The Launcher Or The App Actually Break?
This matters more than it sounds. On Windows, an IDE shortcut can point to a launcher stub, a batch file, or a `.exe` buried inside a versioned folder. After an update, that path sometimes changes and the shortcut goes stale.
Open a terminal and run the executable directly. For JetBrains IDEs you’ll usually find it under something like C:\Program Files\JetBrains\IntelliJ IDEA . For VS Code, it’s the Code.exe in the install directory, or code if it’s on PATH.
If it launches from the terminal but not from the shortcut, you’ve found your problem and it’s a five-second fix. Right-click the shortcut, check the target path, repoint it. Done.
If it silently dies from the terminal too, keep reading. That’s a real failure.
Check The Log Before You Touch Anything
Every serious IDE writes a startup log, and it usually lives in your user profile, not the install directory. For JetBrains products that’s under %LOCALAPPDATA%\JetBrains\. For VS Code it’s in %APPDATA%\Code\logs.
Open the most recent log and scroll to the bottom. Nine times out of ten the last few lines tell you exactly what died: a missing JVM, an incompatible plugin, a lock file it can’t acquire, a config file it refuses to parse.
I’ve seen a single stale plugin block startup completely after a major version bump. The log said so plainly. The fix was renaming the plugins folder and letting the IDE rebuild it.
Kill The Stale Lock File
If the log mentions a lock or a “another instance is running” message but you can’t see one, the previous session crashed and left garbage behind. Look for a .lock file in the config directory and delete it. Same trick applies to a leftover .pid file pointing at a process that no longer exists.
This is common right after an update because the updater sometimes kills the old process uncleanly. It’s also the single most common cause of “nothing happens when I click the icon” on Windows.
The JDK Problem, Which Is Usually The Real Culprit
This is where most people get stuck, and it’s why running two Java versions on one machine is a topic worth understanding separately. IntelliJ and other JVM-based IDEs ship with their own bundled runtime. An update can replace that runtime, and if the bundled JDK fails to unpack or gets blocked, the IDE has nothing to start on.
Check the jbr (JetBrains Runtime) folder in the install directory. It should contain a working bin\java.exe. If the folder is empty or half-populated, the update extract failed, likely because antivirus quarantined files mid-write. This is not hypothetical. Corporate endpoint protection does this constantly.
Same story for standalone JDKs your projects use. An update to the IDE doesn’t touch those, but if you also bumped a JDK at the same time, a broken JAVA_HOME or a duplicate entry on PATH can send the launcher to the wrong runtime. Run where java in a fresh terminal and confirm the first hit is the one you expect. If it’s not, your environment variables need sorting.
Also check that the runtime the IDE wants is actually installed. A major IDE version can drop support for an older bundled JDK and require a newer one. If yours is pinned by policy, the new IDE won’t start until you satisfy it.
Rule Out Antivirus And Windows Defender
Updates write new executables and DLLs to disk. Security software hates that pattern. It’s not unusual for a freshly updated IDE to be scanned, blocked, or partially quarantined on first launch, and the failure looks identical to a crash.
Check your security product’s quarantine or protection history for entries matching the IDE’s install path. If you find one, restore it and add an exclusion for the install directory.
While you’re in Windows settings, glance at disk space. A nearly full system drive stops an update from finishing cleanly, and Microsoft’s own guidance treats low disk space as a common performance and stability problem. Free up space, then retry the launch. You can clear temp files through Settings > System > Storage > Temporary files or run Disk Cleanup.
Corrupt Config And Plugin State
If the binary launches but the window never appears, or it dies during the splash, your config is likely the problem. Settings migrate between versions, and a bad migration can brick startup.
Back up the config directory first. Then rename it, so the IDE treats the next launch as a fresh install. If it starts, you’ve confirmed the cause and can selectively restore pieces of your old config until you find the offender. Nine times out of ten it’s a single plugin, not your settings.
Plugins are worth calling out specifically. A plugin built for the previous major version can crash the whole IDE on load. Disable plugins wholesale by renaming the plugins directory, launch, then re-enable them one at a time. Tedious, but it works.
Roll Back To Confirm, Then Decide
If you’ve checked the log, cleared lock files, verified the runtime, and it still won’t start, roll back. JetBrains Toolbox keeps previous versions around. Standalone installs require downloading the older build from the vendor’s archive. Either way, a rollback tells you whether the update caused this or whether something else on the machine changed at the same time (a driver, an OS patch, a security policy).
That distinction matters. If the old version starts fine and the new one doesn’t, it’s a real bug and worth reporting to the vendor. If both fail, your problem predates the update and you’ve been chasing the wrong thing.
Keep Notes And Keep Backups
The lesson here isn’t exotic. Keep a note of what you changed and when, and keep a backup of the config directory before major updates. A package update that breaks login or startup is rare, but it happens, and the people who recover fastest are the ones who can undo a change instead of rebuilding from scratch.
On Windows specifically, System Restore is your cheapest safety net for IDE and runtime changes. Enable it, note the restore point name before you update, and you’ve got a one-click escape hatch when something breaks the next morning.
The order above is roughly cheapest-first. Shortcut, log, lock file, runtime, antivirus, config, rollback. Skip straight to reinstalling and you’ll lose an hour and probably hit the same wall again on the next update.