Visual Studio Build Tools Cannot Work in HyperV Isolation Mode

[chen-wu]

Describe the bug

Some applications (rc.exe in C++ workload, it is a part of Windows Kit) in Visual Studio Build Tools 2022 cannot start in Hyper-V isolation mode. However, the same image could work in Process isolation mode.

Which .NET image(s) are you using?

dotnet/framework/runtime:4.8-windowsservercore-ltsc2022

Steps to reproduce

Follow the official instruction to install Build Tools with C++ workload.

The Dockerfile is like:

# escape=`

FROM mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2022

# Restore the default Windows shell for correct batch processing.
SHELL ["cmd", "/S", "/C"]

# use command $env:DOCKER_BUILDKIT=1 to enable mount function
RUN --mount=type=bind,from=vs-layout,target=C:\vslayout `
    certutil.exe -f -addstore "Root" "C:\vslayout\certificates\manifestRootCertificate.cer" `
    && certutil.exe -f -addstore "Root" "C:\vslayout\certificates\manifestCounterSignRootCertificate.cer" `
    && certutil.exe -f -addstore "Root" "C:\vslayout\certificates\vs_installer_opc.RootCertificate.cer" `
    && certutil.exe -f -addstore "Root" "C:\vslayout\certificates\Microsoft Windows Code Signing PCA 2024.crt" `
    # Install Build Tools with the Microsoft.VisualStudio.Workload.AzureBuildTools workload, excluding workloads and components with known issues.
    && C:\vslayout\vs_buildtools.exe --quiet --wait --norestart --nocache --noweb `
    --add Microsoft.VisualStudio.Workload.VCTools `
    --add Microsoft.VisualStudio.Component.VC.ATLMFC `
    --add Microsoft.VisualStudio.Component.VC.CLI.Support `
    --add Microsoft.VisualStudio.Component.VC.ATL `
    --includeRecommended `
    || IF "%ERRORLEVEL%"=="3010" (EXIT 0) ELSE (type "%TEMP%\dd_setup_*.log" & EXIT %ERRORLEVEL%)

# Define the entry point for the Docker container.
# This entry point starts the developer command prompt and launches the PowerShell shell.
ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\Common7\\Tools\\LaunchDevCmd.bat", "-arch=amd64", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

Run the image as container.

The x64 rc.exe cannot start, however, the x86 version works.

C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0>x64\rc.exe /?

C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0>x86\rc.exe /?

Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.

Usage:  rc [options] .RC input file
Switches:
   /r       Emit .RES file (optional)
   /v       Verbose (print progress messages)
   /d       Define a symbol
   /u       Undefine a symbol
   /fo      Rename .RES file
   /l       Specify default language using language identifier
   /ln      Specify default language using language name
   /i       Add a path for INCLUDE searches
   /x       Ignore INCLUDE environment variable
   /c       Define a code page used by NLS conversion
   /w       Warn on Invalid codepage in .rc (default is an error)
   /y       Don't warn if there are duplicate control ID's
   /n       Append null's to all strings in the string tables
   /fm      Localizable resource only dll file name
   /q       RC Configuration file for the resource only DLL
   /g       Specify the ultimate fallback language using language identifier
   /gn      Specify the ultimate fallback language using language name
   /g1      Specify if version only MUI file can be created
   /g2      Specify the custom file version for checksum in MUI creation
   /nologo  Suppress startup logo
   /sl      Specify the resource string length limit in percentage
   /8       Enable UTF-8-only mode

I also tried to rebuild the base image with full server instead of the server core with this dockerfile and change the base to windows/server:ltsc2022-amd64. The result is the same.

The Windows Error Log in the container said:

PS C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0> (Get-EventLog application -Index 645).message
Faulting application name: rc.exe, version: 10.0.26100.7705, time stamp: 0x8af15307
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00007ffb4c5cb0c0
Faulting process id: 0x7b4
Faulting application start time: 0x01dcb20d2b400c36
Faulting application path: C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\rc.exe
Faulting module path: unknown
Report Id: 4d15441b-8e31-4a21-bbe0-d8f0fe82f039
Faulting package full name:
Faulting package-relative application ID:

I am using Buildkit 0.28.0 and Containerd 2.2.1, Docker Desktop for Windows 29.2.1 to run these images. Windows is:
Kernel Version: 10.0 26200 (26100.1.amd64fre.ge_release.240331-1435)
Operating System: Microsoft Windows Version 25H2 (OS Build 26200.7840)

Other information

No response

Output of docker version

Client:
 Version:           29.2.1
 API version:       1.53
 Go version:        go1.25.6
 Git commit:        a5c7197
 Built:             Mon Feb  2 17:20:16 2026
 OS/Arch:           windows/amd64
 Context:           desktop-windows

Server: Docker Desktop 4.63.0 (220185)
 Engine:
  Version:          29.2.1
  API version:      1.53 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       6bc6209b
  Built:            Mon Feb  2 17:17:12 2026
  OS/Arch:          windows/amd64
  Experimental:     true

Output of docker info

[lbussell]

[Triage] Hi @chen-wu, thanks for the report -- I suspect that this is an issue with the Windows Container runtime, and not with the .NET Framework images themselves. I'm going to try and reproduce this without using the .NET Framework images as a base to narrow down the root cause.