microsoft / microsoft/vscode-dotnettools

[BUG] C# Dev Kit extension dies on startup within a devcontainer running on Docker Desktop w/ Enhanced Container Isolation enabled.

Open
#1,997 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area-servicehub bug
Dominant language
No language data
Stars
321
Forks
54
Avg merge
2d 19h
Merged PRs (30d)
2

Description

Describe the Issue

C# Dev Kit VSCode Extension Crash

C# Dev Kit crashes when running within DevContainer and Docker Desktop has Enhanced Container Isolation (ECI) enabled.

Log/stack dump

Starting Spawn .NET server...
Using legacy dotnet resolution.
Starting opening a solution...
Starting processing the solution file "/workspaces/dotnet-demo-local/Weather.sln" in Dev Kit server...
Using local .NET runtime at "/root/.vscode-server/data/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/9.0.4arm64aspnetcore/dotnet"
Found installed dotnet location "/usr/lib/dotnet/dotnet" to load projects.

.NET server STDERR: Unhandled exception. 
.NET server STDERR: System.IO.FileNotFoundException: /var/lib/docker/rootfs/overlayfs/104ca69d0efb6448ee03c02596e1f632fc91abaed386006d23025cbc513e3d72/root/.vscode-server/extensions/ms-dotnettools.csdevkit-1.18.25-linux-arm64/components/vs-green-server/platforms/linux-arm64/node_modules/@microsoft/visualstudio-server.linux-arm64/Microsoft.VisualStudio.Code.Server
   at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
   at System.Diagnostics.ProcessModule.get_FileVersionInfo()
   at Microsoft.ServiceHub.Client.HubControllerClient.StartAsync(ServiceHubConfig config, String clientName, CancellationToken cancellationToken)
   at Microsoft.ServiceHub.Client.HubClient.LaunchOrFindControllerAsync()
   at Microsoft.VisualStudio.Threading.AsyncLazy`1.<>c__DisplayClass20_0.<<GetValueAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.ServiceHub.Client.HubClient.GetLocationServiceAsync()
   at Microsoft.ServiceHub.Utility.Shared.ServiceHubRetry.ExecuteAsync[TReturnType](Func`1 actionToExecute, TraceSource logger, ServiceHubRetryConfiguration`1 serviceHubRetryConfiguration, CancellationToken cancellationToken)
   at Microsoft.ServiceHub.Utility.Shared.ServiceHubRetry.ExecuteAsync[TReturnType](Func`1 actionToExecute, TraceSource logger, ServiceHubRetryConfiguration`1 serviceHubRetryConfiguration, CancellationToken cancellationToken)
   at Microsoft.VisualStudio.Threading.AsyncLazy`1.<>c__DisplayClass20_0.<<GetValueAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.ServiceHub.Client.HubClient.GetThisAsRemoteServiceBrokerAsync()
   at Microsoft.VisualStudio.Server.ServiceBroker.Program.RunAsync(Stream rpcStream, String bridgePipeName, ExportProvider exportProvider, Boolean includeServiceHub, String serviceHubConfigPath, Func`2 traceSourceFactory, TraceSource traceSource, TelemetrySession telemetrySession, TelemetryEvent perfTelemetryEvent, CancellationToken cancellationToken)
   at Microsoft.VisualStudio.Server.ServiceBroker.Program.RunAsync(Stream rpcStream, String bridgePipeName, ExportProvider exportProvider, Boolean includeServiceHub, String serviceHubConfigPath, Func`2 traceSourceFactory, TraceSource traceSource, TelemetrySession telemetrySession, TelemetryEvent perfTelemetryEvent, CancellationToken cancellationToken)
   at Microsoft.VisualStudio.Server.ServiceBroker.Program.<>c__DisplayClass9_0.<<BuildCommandLine>b__1>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.AnonymousCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass21_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass18_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__17_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass15_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__4_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass1_0.<<CancelOnProcessTermination>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.InvocationPipeline.<InvokeAsync>g__FullInvocationChainAsync|2_0(InvocationContext context)
   at System.CommandLine.Parsing.ParseResultExtensions.InvokeAsync(ParseResult parseResult, IConsole console, CancellationToken cancellationToken)
   at System.CommandLine.Parsing.ParserExtensions.InvokeAsync(Parser parser, String[] args, IConsole console, CancellationToken cancellationToken)
   at Microsoft.VisualStudio.Server.ServiceBroker.Program.Main(String[] args)
   at Microsoft.VisualStudio.Server.ServiceBroker.Program.<Main>(String[] args)

.NET server STDOUT: [createdump] Gathering state for process 3742 Microsoft.Visua
[createdump] Crashing thread 0e9e signal 6 (0006)

.NET server STDOUT: [createdump] Writing crash report to file /root/.cache/Microsoft/csdevkit/dumps/Microsoft.Visua.3742.dmp.crashreport.json

.NET server STDOUT: [createdump] Crash report successfully written

.NET server STDOUT: [createdump] Writing minidump with heap to file /root/.cache/Microsoft/csdevkit/dumps/Microsoft.Visua.3742.dmp

.NET server STDOUT: [createdump] Written 283140096 bytes (69126 pages) to core file
[createdump] Target process is alive

.NET server STDOUT: [createdump] Dump successfully written in 191ms

.NET server exited with null

Note that the path has some odd, docker path prefix to the actual file. This same thing happens trying to run unit tests on the project from the command line: dotnet test

The project can build and run fine from the command line, however.

Test command crash
$ dotnet test
  Determining projects to restore...
  All projects are up-to-date for restore.
  Weather -> /workspaces/dotnet-demo-local/Weather/bin/Debug/net8.0/Weather.dll
  Weather.Tests -> /workspaces/dotnet-demo-local/Weather.Tests/bin/Debug/net8.0/Weather.Tests.dll
Test run for /workspaces/dotnet-demo-local/Weather.Tests/bin/Debug/net8.0/Weather.Tests.dll (.NETCoreApp,Version=v8.0)
Microsoft (R) Test Execution Command Line Tool Version 17.8.0 (arm64)
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Failed to launch testhost with error: System.IO.FileNotFoundException: Path does not exist: /var/lib/docker/rootfs/overlayfs/104ca69d0efb6448ee03c02596e1f632fc91abaed386006d23025cbc513e3d72/usr/lib/dotnet/dotnet
File name: '/var/lib/docker/rootfs/overlayfs/104ca69d0efb6448ee03c02596e1f632fc91abaed386006d23025cbc513e3d72/usr/lib/dotnet/dotnet'
   at Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.ProcessHelper.LaunchProcess(String processPath, String arguments, String workingDirectory, IDictionary`2 envVariables, Action`2 errorCallback, Action`1 exitCallBack, Action`2 outputCallBack) in /build/dotnet8-cuuDiH/dotnet8-8.0.115-8.0.15/src/vstest/artifacts/source-build/self/src/src/Microsoft.TestPlatform.PlatformAbstractions/common/System/ProcessHelper.cs:line 58
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Hosting.DotnetTestHostManager.LaunchHost(TestProcessStartInfo testHostStartInfo, CancellationToken cancellationToken) in /build/dotnet8-cuuDiH/dotnet8-8.0.115-8.0.15/src/vstest/artifacts/source-build/self/src/src/Microsoft.TestPlatform.TestHostProvider/Hosting/DotnetTestHostManager.cs:line 718
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Hosting.DotnetTestHostManager.LaunchTestHostAsync(TestProcessStartInfo testHostStartInfo, CancellationToken cancellationToken) in /build/dotnet8-cuuDiH/dotnet8-8.0.115-8.0.15/src/vstest/artifacts/source-build/self/src/src/Microsoft.TestPlatform.TestHostProvider/Hosting/DotnetTestHostManager.cs:line 204
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(IEnumerable`1 sources, String runSettings) in /build/dotnet8-cuuDiH/dotnet8-8.0.115-8.0.15/src/vstest/artifacts/source-build/self/src/src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyOperationManager.cs:line 234

Test Run Aborted.

While this was against a local, custom, development container built upon an Ubuntu 24.04 base, I noticed similar behavior when troubleshooting with the pre-built development containers from Microsoft. I finally tracked this behavior down to the Enhanced Container Isolation (ECI) option our organization enables by default.

If I manually symlink to the missing paths, things work as expected. I'm not sure where that erroneous path prefix is getting pulled from. It does not exist (and that hash value path component is different on each launch of the devcontainer).

Steps To Reproduce

No response

Expected Behavior

No response

Environment Information
  • DevContainer launched on both Docker Desktop for Windows or macOS (M3 Pro, 36 GB RAM, v15.4.1, Docker: v4.40.0)
    • Fails when Enhanced Container Isolation (ECI) is enabled on either platform
  • Environment:
dotnet --info
.NET SDK:
 Version:           8.0.115
 Commit:            9c0387c3ea
 Workload version:  8.0.100-manifests.b0a64abb

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  24.04
 OS Platform: Linux
 RID:         ubuntu.24.04-arm64
 Base Path:   /usr/lib/dotnet/sdk/8.0.115/

.NET workloads installed:
 Workload version: 8.0.100-manifests.b0a64abb
There are no installed workloads to display.

Host:
  Version:      8.0.15
  Architecture: arm64
  Commit:       50c4cb9fc3

.NET SDKs installed:
  8.0.115 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.15 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.15 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/lib/dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the failure in a VS Code Dev Container with Docker Desktop Enhanced Container Isolation enabled, using the C# Dev Kit and the reported dotnet test command. Start by comparing behavior with ECI disabled and inspect the .NET server and test-host launch paths shown in the logs. Done means the extension starts and dotnet test launches without the nonexistent Docker rootfs path prefix.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, docker, vscode
Domain
devops, devtools, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.