Net 7 sdk build freezes computer

With a simple hello world console app, building with .Net 7 sdk uses a ton of memory and freezes my computer until it is complete. And it takes much longer to complete than .Net 6 sdk.

class Program
{
    static void Main(string[] args)
    {
        System.Console.WriteLine("Hello World");
    }
}

With command dotnet build -c Release -f net6.0

I only have 8 GB of memory in my computer, so if I build a larger project (like a BenchmarkDotNet project), it consumes 100% of my memory and locks up my computer for several minutes, where .Net 6 sdk uses very little memory and completes in seconds.

I’m on Windows 7 SP1 x64, with AMD Phenom II X6 cpu, 8GB DDR3 memory. .Net SDK 7.0.100-preview.7

[Edit] Also, the process hangs for a little while after the command has completed and the output printed to the console, while .Net 6 sdk immediately terminates when it’s complete (see the trailing memory usage in the image).

[loop-evgeny]

Happens to me as well with .NET SDK 7.0.101, on two Windows 7 x64 SP1 machines. Completely kills each machine (16GB and 32GB RAM) - it uses up not only all physical RAM, but all swap space as well. One of the machines typically blue-screens eventually with a larger project! On a tiny test project it uses ~50 GB RAM, but finishes eventually:

C:\W ork\Play\net7test>dotnet new console
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring C:\W ork\Play\net7test\net7test.csproj:
  Determining projects to restore...
  Restored C:\W ork\Play\net7test\net7test.csproj (in 101 ms).
Restore succeeded.

C:\W ork\Play\net7test>dotnet restore
  Determining projects to restore...
  All projects are up-to-date for restore.

C:\W ork\Play\net7test>dotnet build
MSBuild version 17.4.0+18d5aef85 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
FFFaaiialleiedld e td too t cocr recearateteatee  CC ooCorrreeeCCCLLLRRR,,,   HHRHRERESESUSULT: 0x8UL0LT0T:7: 0 00x00E8x080070070000E0E
  net7test -> C:\W ork\Play\net7test\bin\Debug\net7.0\net7test.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:04:15.17

OK, I get that Windows 7 is “not supported”, but it should’t do that!

I didn’t even want to use .NET 7. I just wanted to update VS to 17.4, but that automatically installed the .NET 7 SDK. The rest of VS 17.4 seems to work fine. If this is not going to be fixed the VS installer should not install .NET 7 SDK on Windows 7. (I tried to unselect that under “Individual components”, but the only option there is “.NET 7.0 Runtime” and unselecting that removes a bunch of other stuff - basically everything .NET-related.) Please do not block the installation of VS 17.4 on Windows 7 altogether, since VS itself works fine.

[IS4Code]

Same issue here. What seems to happen is that building runs NuGet verification on the workload packages, whatever that is, resulting in the parallel execution of these commands:

dotnet nuget verify --all %tmp%\3804909a-e14d-46bb-b026-704e11402577\microsoft.net.sdk.tvos.manifest-7.0.100.msi.x64\16.1.2551\microsoft.net.sdk.tvos.manifest-7.0.100.msi.x64.16.1.2551.nupkg
dotnet nuget verify --all %tmp%\3804909a-e14d-46bb-b026-704e11402577\microsoft.net.workload.emscripten.net6.manifest-7.0.100.msi.x64\7.0.5\microsoft.net.workload.emscripten.net6.manifest-7.0.100.msi.x64.7.0.5.nupkg
dotnet nuget verify --all %tmp%\3804909a-e14d-46bb-b026-704e11402577\microsoft.net.sdk.maccatalyst.manifest-7.0.100.msi.x64\16.2.2054\microsoft.net.sdk.maccatalyst.manifest-7.0.100.msi.x64.16.2.2054.nupkg
dotnet nuget verify --all %tmp%\3804909a-e14d-46bb-b026-704e11402577\microsoft.net.sdk.ios.manifest-7.0.100.msi.x64\16.2.2054\microsoft.net.sdk.ios.manifest-7.0.100.msi.x64.16.2.2054.nupkg
dotnet nuget verify --all %tmp%\3804909a-e14d-46bb-b026-704e11402577\microsoft.net.sdk.macos.manifest-7.0.100.msi.x64\13.1.2054\microsoft.net.sdk.macos.manifest-7.0.100.msi.x64.13.1.2054.nupkg
dotnet nuget verify --all %tmp%\3804909a-e14d-46bb-b026-704e11402577\microsoft.net.sdk.android.manifest-7.0.100.msi.x64\33.0.46\microsoft.net.sdk.android.manifest-7.0.100.msi.x64.33.0.46.nupkg

This matches the lines in dotnet/sdk/version/IncludedWorkloadManifests.txt, but changing that file has no effect. These commands are also invoked when you run dotnet workload update, so you can test that without building the project.

Now the actual issue (as has been pointed out) is that each dotnet instance using any SDK starting from .NET 7 may take up to 8 GB memory. This memory is not actually in active use, and it does not appear in Task Manager or Process Explorer, but it is used and creating 6 dotnet processes will take any reasonable amount of RAM you may have, and the OS starts swapping like crazy.

Finally this lead me to dotnet/runtime#79469. Setting DOTNET_EnableWriteXorExecute=0 eliminated the issue, at least for now. Not sure what it does, not sure why it prevents this behaviour, but I am sure glad it worked.

@timcassell @michaldobrodenka @lorenblue @Pyrdacor @tapika @loop-evgeny @pkorsukov Tagging to help fellow Windows 7 supporters 😉