sdk: 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).

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 6
Comments: 28 (1 by maintainers)

Most upvoted comments

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 😉

IS4Code on Jun 7, 2023

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.

loop-evgeny on Dec 15, 2022

“Not supported” is fine with me, as long as it works, which it does. Just don’t artificially prevent me from installing it is all I’m asking.

loop-evgeny on Dec 15, 2022

I use a global.json with SDK 6 as a workaround. If you’re curious you can find how it’s setup here: https://learn.microsoft.com/en-us/dotnet/core/versions/selection

Pyrdacor on Nov 24, 2022

I’ve created an issue - similar problem on Windows10 https://github.com/dotnet/runtime/issues/87220

michaldobrodenka on Jun 7, 2023

.Net 7 is not supported on Windows 7

Then why does it install and let you try to build without telling you it’s not supported? Where’s the documentation that says it’s not supported? We’re talking about the sdk itself, not visual studio.

does this reproduce on supported OS versions?

@lorenblue Already mentioned that this issue occurs on Ubuntu also.

timcassell on Nov 25, 2022

Yeah have the same issue as well after upgrading Visual Studio to the latest version and the SDK got updated. 😕 Can’t compile anymore. This is urgent!!!

It kills my PC completely. I am at Win7 x64 as well and also have 8GB which are eaten up by dotnet. It starts at 1GB and then goes up by 2-3 GB per second until all is consumed. Then the PC is not responding anymore and dotnet fails some while after and prints funny things like “FFFFFFFaaaaaaiiiiiiilllllllleeeeeeedddddd…”. I guess because of the freezing system. Unfortunately even after those errors the memory consumption isn’t lowered.

Strange is that there are 3 dotnet instances in my case and they all consume around 500MB of memory. I don’t see the huge memory consumption in the process tab of Windows but in the performance tab. So maybe there is some service started which consumes the memory? Feels a bit like a virus. 😄

Trying to kill a dotnet process (this takes long until the cursor can move there and you need to start the task manager beforehand) again freezes the whole PC.

Pyrdacor on Nov 24, 2022

Still an issue with the new released SDK (7.0.100). I am also getting errors with the build that I am not getting in SDK 6 when I try to compile and run BenchmarkDotNet:

FFaaiilleedd  ttoo  ccrreeaattee  CCoorreeCCLLRR,,  HHRREESSUULLTT::  00xx88000077000000EE

Failed to create CoreCLR, HRESULT: 0x8007000E
C:\Program Files\dotnet\sdk\7.0.100\Roslyn\Microsoft.CSharp.Core.targets(79,5): error : Failed to create CoreCLR, HRESULT: 0x8007000E [C:\BenchmarkDotNet\src\BenchmarkDotNet.Annotations\BenchmarkDotNet.Annotations.csproj::TargetFramework=netstandard2.0]

The build failed. Fix the build errors and run again.

timcassell on Nov 9, 2022