IntelliJ IDEA is usually the stronger choice for diagnosing stuck Java and Kotlin debug sessions, while Visual Studio Code is often quicker for lighter projects and configuration fixes. If you keep seeing “Paused in Debugger” and the app refuses to continue, the best tool depends on what caused the pause: thread deadlock, conditional breakpoint, async call, extension bug, or a bad launch file.
TLDR: Use IntelliJ IDEA when your stuck session involves JVM threads, Spring Boot, Maven, Gradle, Kotlin coroutines, or hard-to-read call stacks. Use Visual Studio Code when you need fast checks on Node.js, Python, containers, or simple breakpoint settings. In one common team scenario, a backend developer can lose 12 to 20 minutes per stuck session if they inspect only the top call stack instead of checking all threads. For example, a “frozen” API request may not be frozen at all; it may be waiting on a locked database connection while the debugger is paused on another thread.
Why “Paused in Debugger” Feels So Annoying
The message sounds harmless. It is not. A paused debugger can block timers, hold locks, delay HTTP responses, freeze UI updates, and make a healthy program look broken.
Honestly, it feels like the debugger is gaslighting you when the code looks fine but the app sits there doing nothing. You press continue. Nothing happens. You stop and restart. Same result. After a few minutes, you start blaming the framework, the IDE, the runtime, and possibly yourself.
The real issue is usually one of these:
- A breakpoint is being hit repeatedly, often inside a loop or polling method.
- A conditional breakpoint is slow or evaluates with side effects.
- Another thread is suspended and holding a lock.
- The debug adapter is out of sync with the running process.
- Hot reload or hot swap failed, leaving old code in memory.
- The launch configuration is wrong, especially in VS Code.
IntelliJ IDEA: Better Deep Inspection, Less Guesswork
IntelliJ IDEA shines when the stuck session is not obvious. Its debugger is tightly built around the JVM, so Java and Kotlin developers get richer clues without installing a pile of extras.
The biggest strength is the Threads view. When one request is paused, IntelliJ makes it fairly easy to see what every thread is doing. This matters. A web app can appear stuck because the debugger suspended all threads, or because one thread is holding a monitor while another waits for it.
IntelliJ also handles smart step into extremely well. When a line contains five method calls, you can choose exactly which one to enter. That saves time. It drives me crazy that in weaker debugging setups, stepping into a line can send you through ten layers of framework code before you reach the method you care about.
For stuck sessions, IntelliJ gives you strong tools:
- Thread dumps from inside the IDE.
- Breakpoint groups for turning related breakpoints on or off.
- Exception breakpoints with filters.
- Method breakpoints, useful but sometimes slow.
- Evaluate Expression with solid JVM context.
- Drop Frame for rerunning a section without restarting.
The downside is weight. IntelliJ can feel heavy on large enterprise projects. Indexing, Gradle sync, and plugin conflicts can slow the first few minutes of troubleshooting. If the IDE itself is under pressure, the debugger may feel sluggish too.
Visual Studio Code: Faster Starts, More Setup Traps
Visual Studio Code is excellent when the problem is close to configuration. It opens fast, lets you inspect launch.json, and works across stacks. Node.js, Python, Go, PHP, Rust, Java, and Docker workflows all fit into the same editor.
That flexibility has a price. Debugging depends on extensions, adapters, runtime versions, and workspace settings. If one piece is slightly wrong, “Paused in Debugger” can become a vague symptom instead of a useful clue.
Common VS Code causes include:
- Wrong program path in
launch.json. - Source maps not matching compiled JavaScript or TypeScript.
- Remote container paths mapped incorrectly.
- Auto attach catching a process you did not mean to debug.
- Stale breakpoints left in generated files.
- Debugger extension bugs after an update.
VS Code is especially good at quick restarts. Stop. Edit config. Start again. You can do that in seconds. For frontend and Node.js work, that speed is a big win.
Still, thread-heavy debugging is not as comfortable as IntelliJ. Java support has improved a lot, but IntelliJ still gives a more polished experience for JVM internals. VS Code can show threads and call stacks, but the view often feels more adapter-driven and less integrated.
Image not found in postmeta
Side-by-Side: Which Tool Helps More?
| Problem | IntelliJ IDEA | Visual Studio Code |
|---|---|---|
| Java thread deadlock | Excellent, strong thread dump tools | Good, but less smooth |
| Spring Boot request stuck | Excellent, deep JVM visibility | Good with Java extensions |
| Node.js breakpoint loop | Usable | Excellent, fast and direct |
| Bad debug config | Clear for JVM projects | Excellent, config is easy to edit |
| Remote container debugging | Good, often heavier | Very good, common workflow |
| Conditional breakpoint slowdown | Good controls and clear options | Good, depends on adapter |
First Checks When a Debug Session Gets Stuck
Do not restart immediately. That can erase the clue. Spend 60 seconds checking the obvious things first.
- Look at all threads. Do not trust only the current call stack.
- Check breakpoint settings. Disable conditional, logging, and method breakpoints.
- Resume one thread versus all threads. In JVM debugging, suspension policy matters.
- Inspect locks and waiting states. A blocked thread often explains the freeze.
- Check whether the same breakpoint keeps firing. Loops and schedulers are common offenders.
- Restart only after saving evidence. Take a thread dump or copy the call stack first.
In IntelliJ, pay close attention to Suspend: Thread versus Suspend: All in breakpoint settings. For server apps, suspending all threads can make the whole service appear broken. In VS Code, check whether the breakpoint maps to the file you think it maps to, especially with TypeScript, bundlers, or container paths.
Conditional Breakpoints: Helpful, Then Painful
Conditional breakpoints are great until they are not. A condition that calls a method can change program behavior. A condition that runs on every loop iteration can slow execution to a crawl.
In IntelliJ, complex breakpoint conditions are easier to inspect and edit. You also get clearer control over hit counts and filters. In VS Code, conditional breakpoint support is strong for many languages, but the exact behavior depends on the debug adapter.
A practical rule: if a debug session feels stuck, disable every conditional breakpoint first. If performance suddenly returns, add them back one at a time.
Image not found in postmeta
Remote and Container Debugging
VS Code is often more comfortable for container-based work. Dev Containers, remote SSH, and workspace-level settings make it quick to attach to services. If your “paused” state comes from path mapping, ports, or attach settings, VS Code may help you fix it faster.
IntelliJ is still powerful for remote JVM debugging. It handles remote attach well and gives better JVM-level information once connected. The setup can take longer, but the inspection quality is usually worth it for serious backend issues.
Which One Should You Use?
Pick IntelliJ IDEA if your stuck debug sessions involve Java, Kotlin, Spring, Gradle, Maven, thread pools, locks, or coroutines. It gives you better visibility into what the runtime is actually doing.
Pick Visual Studio Code if your work spans several languages, starts and stops often, or depends on containers and editable launch files. It is quicker for config mistakes and lighter workflows.
The best troubleshooting habit is tool-independent: check threads, breakpoint rules, and source mapping before restarting. A stuck debug session is rarely random. IntelliJ helps you prove what the JVM is doing. VS Code helps you fix the wiring fast. Use the one that exposes the real cause with the fewest clicks.
