MSBuild crashes if environment variable too long
See original GitHub issue.NET rejects env var values over 32KB with ArgumentException. MSBuild sets environment varibles in several places and in this place at least does not handle that nicely. In this particular callstack it should perhaps just not set that environment variable. Possibly it should fail at initialization though if there’s an environment variable that is so long it wouldn’t be able to reset it when the build is done.
Note there’s a (shorter) limit on env var name also.
https://github.com/dotnet/coreclr/issues/9793
06:57:53 Starting Build at 6:57:53.56
06:57:53 BUILD: Commencing CoreCLR Repo build
06:57:53 BUILD: Checking prerequisites
06:57:56 BUILD: Using environment: "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat"
06:58:02 Installing .NET Version Manager to C:\Users\dotnet-bot.dnx\bin
06:58:02 Creating destination folder 'C:\Users\dotnet-bot.dnx\bin' ...
06:58:02 Installing 'dnvm.ps1' to 'C:\Users\dotnet-bot.dnx\bin' ...
06:58:02 Installing 'dnvm.cmd' to 'C:\Users\dotnet-bot.dnx\bin' ...
06:58:02 Adding C:\Users\dotnet-bot.dnx\bin to Process PATH
06:58:02 Adding C:\Users\dotnet-bot.dnx\bin to User PATH
06:58:06 Installing dotnet cli...
06:58:13 Restoring BuildTools version 1.0.27-prerelease-01209-01...
06:58:13 Initializing BuildTools ...
06:58:52 Updating CLI NuGet Frameworks map...
06:58:52 Done initializing tools.
06:58:52 Running: D:\j\workspace\x86_checked_w---b3a226f6\Tools\dotnetcli\dotnet.exe D:\j\workspace\x86_checked_w---b3a226f6\Tools\run.exe D:\j\workspace\x86_checked_w---b3a226f6\config.json build -Project=D:\j\workspace\x86_checked_w---b3a226f6\build.proj -generateHeaderWindows -NativeVersionHeaderFile="D:\j\workspace\x86_checked_w---b3a226f6\bin\obj_version.h" -BuildOS=Windows_NT -BuildType=Checked -BuildArch=x86
06:58:52 Running: D:\j\workspace\x86_checked_w---b3a226f6\Tools\msbuild.cmd /nologo /verbosity:minimal /clp:Summary /maxcpucount /nodeReuse:false /l:BinClashLogger,Tools/net45/Microsoft.DotNet.Build.Tasks.dll;LogFile=binclash.log D:\j\workspace\x86_checked_w---b3a226f6\build.proj /p:__BuildType=Checked /p:__BuildArch=x86 /p:__BuildOS=Windows_NT /t:GenerateVersionHeader /p:GenerateVersionHeader=true /p:NativeVersionHeaderFile=D:\j\workspace\x86_checked_w---b3a226f6\bin\obj_version.h
06:59:00
06:59:00 Unhandled Exception: Microsoft.Build.Shared.InternalErrorException: MSB0001: Internal MSBuild Error: Environment variable name or value is too long.
06:59:00 =============
06:59:00 System.ArgumentException: Environment variable name or value is too long.
06:59:00 at System.Environment.SetEnvironmentVariable(String variable, String value)
06:59:00 at Microsoft.Build.BackEnd.InProcNode.HandleShutdown(Exception& exception)
06:59:00 at Microsoft.Build.BackEnd.InProcNode.Run(Exception& shutdownException)
06:59:00
06:59:00 ---> System.ArgumentException: Environment variable name or value is too long.
06:59:00 at System.Environment.SetEnvironmentVariable(String variable, String value)
06:59:00 at Microsoft.Build.BackEnd.InProcNode.HandleShutdown(Exception& exception)
06:59:00 at Microsoft.Build.BackEnd.InProcNode.Run(Exception& shutdownException)
06:59:00 --- End of inner exception stack trace ---
06:59:00 at Microsoft.Build.Shared.ErrorUtilities.ThrowInternalError(String message, Exception innerException, Object[] args)
06:59:00 at Microsoft.Build.BackEnd.InProcNode.Run(Exception& shutdownException)
06:59:00 at Microsoft.Build.BackEnd.NodeProviderInProc.InProcNodeThreadProc()
06:59:00 at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
06:59:00 at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
06:59:00 at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
06:59:00 at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
06:59:00 at System.Threading.ThreadHelper.ThreadStart()
06:59:01 Command execution failed with exit code -532462766.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:2
- Comments:7 (7 by maintainers)
Top Results From Across the Web
MSBuild crashes if environment variable too long #1765
I opened dotnet/corefx#16766 to accept longer variables but there will always be a limit and MSBuild should not crash.
Read more >Why does visual studio crashes on opening a solution ...
Found that environment variable on the machine was too long got rid of some unecessary ones.
Read more >MSBuild fails: Environment variable too long
Hi Support Team, we use a ContinuaCI Build Server to build C# programs via FinalBuilder-Actions ('Build VS.Net Solution' and 'MSBuild ...
Read more >VS2022 debugger crash with error Failed to read ...
I received the "Failed to read environment variable [DOTNET_STARTUP_HOOKS]" message when I tried to create a new project after upgrading Visual ...
Read more >Internal MSBuild Error: Already registered for build-time
Looking at MSBuild code, seems to be a threading bug. I reduced concurrent builds from 8 to 1 to work around this issue....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

My guess is that Windows raised the limit again. Feel free to offer an issue PR for their docs.
This demonstrates why it was a good change to make the OS validate the length, rather than .NET. We’d have gotten it wrong again if we did it.
What you do if you get the exception is a decision to make, I guess either fail the build, silently continue, or log it could not be set and continue – I’m guessing the latter.