Vscode-java-debug: CreateProcess error=206, The filename or extension is too long

Created on 24 Oct 2017  路  28Comments  路  Source: microsoft/vscode-java-debug

/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:28 Failed to launch debuggee VM. Reason: java.io.IOException: Cannot run program "F:\job\2017\vscode\dev_tools\20170918\Java\jdk1.8.0_91\jre\bin\java": CreateProcess error=206, The filename or extension is too long.

bug

Most helpful comment

You have any solution, because I have the same problem.

All 28 comments

@testforstephen please follow up with this.

This issue has been closed automatically because it needs more information and has not had recent activity. Please reach out if you have or find the answers we need so that we can investigate further.

What information is needed? I am having the issue and can provide additional information, but there's no clear request in this ticket's history.

Could you tell us your classpath length? we want to find the length limitation for CreateProcess, then find a project to reproduce the problem.

Windows Create Process has 32K limitation on the command line. [Source]
Need find some way to pass the long classpath to Java program.

Sorry, I'm new to Java - how do I determine the classpath value/length?

@jamestharpe thanks for response. we have figured out the maximum command line length. It's 32K(32768) characters. Will provide a fix for the long classpath case.

@testforstephen It can easily be reproduced adding to a simple Spring Boot application with the dependency as below:

dependencies {
    compile("org.springframework.boot:spring-boot-starter-data-mongodb")
    compile('org.springframework.boot:spring-boot-starter-web')
    compile('org.apache.spark:spark-core_2.11:2.3.2')
    compile('org.apache.spark:spark-sql_2.11:2.3.2')
    compile('org.mongodb.spark:mongo-spark-connector_2.11:2.3.1')
    testImplementation('org.springframework.boot:spring-boot-starter-test')
}

I can share the entire gradle project if you want.

@EnriqueEll Thanks for the feedback, appreciate a lot if you can share the entire gradle project to help us to verify the bug.

You have any solution, because I have the same problem.

I am getting this error in windows 10.

Failed to launch debuggee VM. Reason: java.io.IOException: Cannot run program "C:\Program Files\Java\jdk-10.0.2\bin\java" (in directory "c:\Users\Sumanth\Documents\turbo-workspace\dev-for-uat-release18-elb"): CreateProcess error=206, The filename or extension is too long
com.microsoft.java.debug.core.DebugException: Failed to launch debuggee VM. Reason: java.io.IOException: Cannot run program "C:\Program Files\Java\jdk-10.0.2\bin\java" (in directory "c:\Users\Sumanth\Documents\turbo-workspace\dev-for-uat-release18-elb"): CreateProcess error=206, The filename or extension is too long
at com.microsoft.java.debug.core.adapter.handler.LaunchWithoutDebuggingDelegate.launchInternally(LaunchWithoutDebuggingDelegate.java:94)
at com.microsoft.java.debug.core.adapter.handler.LaunchRequestHandler.launch(LaunchRequestHandler.java:142)
at com.microsoft.java.debug.core.adapter.handler.LaunchRequestHandler.handleLaunchCommand(LaunchRequestHandler.java:90)
at com.microsoft.java.debug.core.adapter.handler.LaunchRequestHandler.handle(LaunchRequestHandler.java:57)
at com.microsoft.java.debug.core.adapter.DebugAdapter.lambda$dispatchRequest$0(DebugAdapter.java:85)
at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at com.microsoft.java.debug.core.adapter.DebugAdapter.dispatchRequest(DebugAdapter.java:84)
at com.microsoft.java.debug.core.adapter.ProtocolServer.dispatchRequest(ProtocolServer.java:118)
at com.microsoft.java.debug.core.protocol.AbstractProtocolServer.lambda$new$0(AbstractProtocolServer.java:78)
at io.reactivex.internal.observers.LambdaObserver.onNext(LambdaObserver.java:60)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:200)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:252)
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:61)
at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:52)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)

Failed to launch debuggee VM. Reason: java.io.IOException: Cannot run program "C:\Program Files\Java\jdk-10.0.2\bin\java" (in directory "c:\Users\Sumanth\Documents\turbo-workspace\dev-for-uat-release18-elb"): CreateProcess error=206, The filename or extension is too long
com.microsoft.java.debug.core.DebugException: Failed to launch debuggee VM. Reason: java.io.IOException: Cannot run program "C:\Program Files\Java\jdk-10.0.2\bin\java" (in directory "c:\Users\Sumanth\Documents\turbo-workspace\dev-for-uat-release18-elb"): CreateProcess error=206, The filename or extension is too long
at com.microsoft.java.debug.core.adapter.handler.LaunchWithoutDebuggingDelegate.launchInternally(LaunchWithoutDebuggingDelegate.java:94)
at com.microsoft.java.debug.core.adapter.handler.LaunchRequestHandler.launch(LaunchRequestHandler.java:142)
at com.microsoft.java.debug.core.adapter.handler.LaunchRequestHandler.handleLaunchCommand(LaunchRequestHandler.java:90)
at com.microsoft.java.debug.core.adapter.handler.LaunchRequestHandler.handle(LaunchRequestHandler.java:57)
at com.microsoft.java.debug.core.adapter.DebugAdapter.lambda$dispatchRequest$0(DebugAdapter.java:85)
at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at com.microsoft.java.debug.core.adapter.DebugAdapter.dispatchRequest(DebugAdapter.java:84)
at com.microsoft.java.debug.core.adapter.ProtocolServer.dispatchRequest(ProtocolServer.java:118)
at com.microsoft.java.debug.core.protocol.AbstractProtocolServer.lambda$new$0(AbstractProtocolServer.java:78)
at io.reactivex.internal.observers.LambdaObserver.onNext(LambdaObserver.java:60)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:200)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:252)
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:61)
at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:52)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)

Gentlemen, please could you do something about this problem as it practically renders VSCode unable to debug any non-trivial Spring Boot project on Windows!

The problem is, as @testforstephen pointed out, with Windows command line length limit which is 32768 characters.

It is also rather simple to reproduce as @EnriqueEll has shown: Once you have some very basic Gradle project for Spring Boot application (created with Spring Initializr, https://start.spring.io/) e.g.:

buildscript {
    ext {
        springBootVersion = '2.0.6.RELEASE'
    }
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    }
}

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'

group = 'com.necne'
version = '0.0.1'
sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    implementation('org.springframework.boot:spring-boot-starter-data-jpa')
    implementation('org.springframework.boot:spring-boot-starter-web')
    runtimeOnly('org.springframework.boot:spring-boot-devtools')
    runtimeOnly('com.h2database:h2')
    testImplementation('org.springframework.boot:spring-boot-starter-test')

    implementation("org.springframework.boot:spring-boot-starter-data-mongodb")
    implementation('org.mongodb.spark:mongo-spark-connector_2.11:2.3.1')

    // compile('org.apache.spark:spark-core_2.11:2.3.2')
    // compile('org.apache.spark:spark-sql_2.11:2.3.2')

    implementation("io.springfox:springfox-swagger2:2.0.2")
    implementation("io.springfox:springfox-swagger-ui:2.0.2")
}

It starts and debugs correctly until you un-comment two commented lines in dependencies section when it displays said "206" error. Also if you use command line sequence gradle clean build and then gradle bootRun it will fail to start.

This problem has long been known for long time (e.g. https://github.com/gradle/gradle/issues/1989, https://virgo47.wordpress.com/2018/09/14/classpath-too-long-with-spring-boot-and-gradle/) and there are some ways to deal with, most notably, there is a way to make Gradle build a .jar with paths for all of the classes referenced. There is a plugin for Gradle (ManifestClasspath) which has a bug rendering it unusable for paths with spaces and there is a number of solutions involving modification of build.gradle so that it creates appropriate .jar.

All of the tools had to deal with this in some way, e.g. InteliJ IDEA has appropriate setting in project settings:

shorten-command-line

So generally if I understand things correctly there is a need to modify command line that invokes debug session to include classpath.jar and exclude all paths passed explicitly. This should be possible to do using command in launch.json but my attempts to do so were unsuccessful - probably there is something underneath that passes the paths even if args in launch.json try to pass the name of the classpath.jar.

Sorry for the late response. Just got back from vacation. I'm trying to fix this problem. The idea is adding a new option shortenCommandLine in launch.json to control how to handle the command line.

The new option provides three possible values: none, jarmanifest, argfile.

  • none: keep the default behavior.
  • jarmanifest: generate the classpath parameters to a temp classpath.jar, and pass it to the java command line.
  • argfile: generate the classpath parameters to a temp argfile, and pass it to the java command line. This value only applies to java 9 and higher.

Sorry for the late response. Just got back from vacation. I'm trying to fix this problem. The idea is adding a new option shortenCommandLine in launch.json to control how to handle the command line.

The new option provides three possible values: none, jarmanifest, argfile.

  • none: keep the default behavior.
  • jarmanifest: generate the classpath parameters to a temp classpath.jar, and pass it to the java command line.
  • argfile: generate the classpath parameters to a temp argfile, and pass it to the java command line. This value only applies to java 9 and higher.

Looking forward to get your fix

@testforstephen The idea looks excellent! Exactly what is needed to straighten something that is unnecessarily convoluted. ;-) Looking forward for the modifications! Please let me know when this can be tested or if I can help in any other way!

Add a new value auto to smartly decide to shorten the classpath if necessary. So at most cases, you don't need care about the new config, it will auto handle the long command line. Below is the doc to explain each values.

shortenCommandLine - When the project has long classpath or big VM arguments, the command line to launch the program may exceed the maximum command line string limitation allowed by the OS. This configuration item provides multiple approaches to shorten the command line. Defaults to auto.

  • none - Launch the program with the standard command line 'java [options] classname [args]'.
  • jarmanifest - Generate the classpath parameters to a temporary classpath.jar file, and launch the program with the command line 'java -cp classpath.jar classname [args]'.
  • argfile - Generate the classpath parameters to a temporary argument file, and launch the program with the command line 'java @argfile [args]'. This value only applies to Java 9 and higher.
  • auto - Automatically detect the command line length and determine whether to shorten the command line via an appropriate approach.

Hi! May I ask, when do you plan to release milestone 0.17.0? I am very eager to test, especially the above and it seems that all the issues are fixed?

@bartosz-antosik We plan to hava a release at March 6th.

It seems to be working fine on auto! Have not tested on specific settings. If you need/want to, let me know. ;-) Many thanks!

@bartosz-antosik Nice to hear that works. Thanks for the quick verification.
auto is recommended. It will smartly decide the shorten mechanism.

Hello,
I am having same problem. Where exactly do we set auto?

auto is the default value. did you try other option jarmanifest?

I have similar problem, we use mks bash shell to build my legacy code that fails with "CreateProcess error=206, The filename or extension is too long"
How can i use this solution to fix my problem?

@testforstephen I'm having the same error (" CreateProcess error=206, The filename or extension is too long") and have tried all of the above vonfigurations for "shortenCommandLine". Each time I still get error=206. Has there been any more work done on this issue since your last comment?

@abyrnensip The debugger will launch your program in terminal by default, and most terminal has limitation at the command line length. Could you share your terminal screenshot?

Also you could try to launch your program in DEBUG CONSOLE via changing the setting to "java.debug.settings.console": "internalConsole"

@testforstephen Thanks for the quick reply, After some struggle my team and I found a solution to the issue, simply a piece of the pom.xml from spring framework that had been commented out by default for some reason and needed to be uncommented. I'll leave the piece here for future reference for anyone else that comes across the issue:

        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <fork>false</fork>
            </configuration>
        </plugin>

The line inside the configuration was what needed to be uncommented.

@abyrnensip was right. Using fork at false fixed my issue.

Was this page helpful?
0 / 5 - 0 ratings