[WSL] Breakpoints fail to bind when attaching to JVM in WSL2 after Debugger for Java 0.58.3 update; rollback fixes #611

Activity

1. github-actions

   added

   ai-triaged

   bug

   on Nov 14, 2025
2. github-actions commented on Nov 14, 2025

   

   github-actionsbot

   on Nov 14, 2025 – with GitHub Actions

   More actions

   Hi Clerton Sampaio (@clertonbruno), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

   Suggestions:

   • Use source mapping so the debugger can bind breakpoints to files under WSL2. In your launch.json attach configuration add something like:

   {
     "type": "java",
     "request": "attach",
     "hostName": "127.0.0.1",
     "port": 5005,
     "sourcePaths": [
       {
         "remoteRoot": "/home/your-user/your-project",
         "localRoot": "${workspaceFolder}"
       }
     ],
     "trace": "verbose"
   }

   – See Remote debug docs: https://code.visualstudio.com/docs/java/java-debugging#_configure-the-remote-debug-settings

   • Enable verbose logging to capture why breakpoints don’t bind:
   – Add "trace": "verbose" and inspect the DEBUG CONSOLE for messages about class loading and breakpoint mapping.

   • As a temporary workaround, rollback to Debugger for Java 0.58.2 & Language Support for Java 1.46.0.

   • If this persists, please file an issue including the verbose logs.

   High-confidence references:

   • Breakpoints not working after recent update (similar symptom of ignored breakpoints) — microsoft/vscode-java-debug#1364

   Other references with low confidence

   • Breakpoints not working at all in 0.58.x series — microsoft/vscode-java-debug#1531
   • Spring/WSL2 debug lands in platform classes, not user code — microsoft/vscode-java-debug#795

   The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!
3. wenytang-ms commented on Apr 28, 2026

   

   wenyt (wenytang-ms)

   on Apr 28, 2026

   Contributor

   More actions

   Clerton Sampaio (@clertonbruno) Thanks for the report. The symptom suggests the breakpoint may actually be hit and the debuggee thread is suspended, but the client
   fails to resolve/show the source for the stopped stack frame.

   Could you help collect a bit more information?

   1. Please try this version matrix:

      • Debugger for Java 0.58.3 + Language Support for Java 1.46.0
      • Debugger for Java 0.58.2 + Language Support for Java 1.47.0
      • latest Debugger for Java + latest Language Support for Java

   2. Please share your full launch.json attach configuration, especially hostName, port, projectName, and sourcePaths.

   3. Please share the relevant paths:

      • Windows workspace path
      • WSL project path
      • the command/current directory used to start the JVM
      • the source file path and package/class name where the breakpoint is set

   4. Please enable "trace": "verbose" and attach the Java Debug logs from session start until the request hangs. The most useful
      parts are setBreakpoints, stopped, and stackTrace responses, especially the source.path values.

   5. When the request hangs, does the Call Stack view show a stopped thread, Unknown Source, or nothing at all?

   This will help us determine whether the regression is in the debug adapter or in JDT-LS/Eclipse source lookup/path mapping under WSL.