Error c3859 failed to create virtual memory for pch

derpirscherderpirscher

12.9k3 gold badges15 silver badges35 bronze badges

ScottScott

3563 silver badges10 bronze badges

GeordieGeordie

1,8141 gold badge23 silver badges30 bronze badges

Our builds were failing in our Jenkins CI pipeline due to PCH and memory issues.

Our problem was that WinRM had a low limit for the allowed shell memory.

After updating this, and setting it to unlimited, we are not getting any more memory related issues with builds.

winrm.cmd set winrm/config/winrs @{MaxMemoryPerShellMB="0"}

Some background:

• Our Windows builds are done in Amazon AWS AMIs
• WinRM is the remote shell that Jenkins uses to connect to the AMI
• We use packer to set up the AMIs
• The above command was added to the packer bootstrap file
• The above command comes from: Configure Maximum Powershell Memory in Windows Server
• More about the quota management: Quota Management for Remote Shells

answered Jan 13, 2021 at 11:45

dgnuffdgnuff

3,0352 gold badges18 silver badges31 bronze badges

valentinbreiz

changed the title
Build errors : Failed to create virtual memory for PCH and others

Build errors : Failed to create virtual memory for PCH / Compiler is hout of heap space

Jan 15, 2020

valentinbreiz

changed the title
Build errors : Failed to create virtual memory for PCH / Compiler is hout of heap space

Build errors : Failed to create virtual memory for PCH / Compiler is out of heap space

Jan 15, 2020

Recently, c++20 came out and I updated one of my big projects to c++20, however I am running into some compilation errors that are beyond my understanding as of this moment.

The error(s) in question are:
C1076 compiler limit: internal heap limit reached
C3859 Failed to create virtual memory for PCH

I’ve been trying to mess around with the virtual memory allocation as a desperate attempt to fix it.

The only «fix» I’ve managed to get to so far is to just keep building after these errors are hit, and after a build or two, it successfully builds and runs without any issues.

Any ideas? Can also upload logs and the equivalent if required.

Thanks in advance.

EDITS/ADDITIONAL INFORMATION:
Using the inbuilt compiler in Visual Studio 2019 — ISO C++20 Standard

M’ok, 2019 has some problems with C++20, you should set the C++ language standard to c++:latest instead C++20.

I’d recommend getting VS 2022, it works better than 2019. And it can use the C++20 language standard instead of latest.

Of course VS 2022 requires you are Windows x64. If you are 32-bit you are kinda stuck with VS 2019.

I have both 2019 and 2022 installed, Community editions, and I’ve found 2022 to be less twitchy than 2019, especially when using C++20 language features.

And consider not using precompiled headers if you can, they’ve been causing problems for a long time, since VS 6 that I’ve noticed. The very small amount of time saved using them is not worth the problems they can cause.

When I start a new project/solution I use the Windows Desktop Wizard project template so I can specify what the application type is — Console, Desktop (WinAPI), Dynamic Library or Static Library — and select the «Empty Project» check box. No files are added to the project so I can add what files I need/want. Now I don’t have to deal with precompiled headers. Less problems that way.

PCH refers to Pre Compiled Header.

Have you tried a complete Rebuild Solution as opposed as just a Rebuid?

What’s the setting for PCH in properties? I don’t use them as this kept causing build issues.

If you consume C++20 modules, stdlib or custom modules, using precompiled headers can on occasion really make VS go loopy if you don’t rebuild the entire project/solution.

Another reason why I don’t let VS use the danged «feature.»

The personal project I have is kind of a «rip-off» from work as I’ve been assigned the memory management of our projects, and considering the size of the codebase, solutions, etc, PCH is a solid solution to spare hours, maybe even days to compile for ourselves.
Apart from trying to see the positives in it, it’s what’s been used for a long time, and deconstructing the PCH might not be very desirable.

I make sure that VS is up to date, and I was hoping that updating it would solve it, but alas, it didn’t.

I have tried a couple things;
— Clean solution -> Build Solution
— Clean Solution -> Rebuild Solution
— Fresh «install» of the project through version control -> Build

Well, I’ve set the Precompiled Header to «Use (/Yu)», the name for the header file that is the PCH, and set a PCH Output File as well.

Yeah it seems like PCH makes things a bit unstable.
I’m not too well versed in it, but it really just seems like there’s not enough space for the PCH to do it’s thing, as building it 2-3 times in a row just removes the issue entirely at the last build and runs as it should.
So the size of a PCH I can understand can get a bit big, however the bit where it «fails to allocate virtual memory», I fail to see the connection.

Thanks for your advice and help so far.

That is an option, however not a highly desirable one.
The difference in compilation time would be enormous, might have to if there is no solution to this, but until hope is lost, I wish to attempt.

If I do find anything, I’ll post it here.

The difference in compilation time would be enormous,

Perhaps not as much as you might think. VS now does incremental compilation of only those functions which have changed. If they haven’t changed then they are copied from the previous compilation.

Are you sure about that? Have you actually done tests? The MSVC++ compiler is a lot more efficient than it used to be. The underlying compiler in 2022 is better, marginally, than 2019’s. 2019 is still speedy when doing incremental builds.

Right now using precompiled headers is a huge time waste since you can’t get your project(s) to compile.

Not using PCH will take some extra time the first compilation, especially if done as a full rebuild. Builds after that should be speedier since they will be incremental builds.

I’ll give it a go and not use PCH, cause truth be told I have not compared the compilation speed of the two alternatives.

There is only but one fix I have found for this error, and that is to simply upgrade to VS 2022 instead of VS 2019.

Thank you all kindly for your help, suggestions and explanations.

If you can use c++ modules, there should be a dramatic improvement on compilation times compared to normal compilation methods, especially if the project is large.

George P has done it on windows — he knows all about it :+)

Edit: I am sure George made some posts about it, you could search for them.

Any time I create a new project in VS I always choose to not use precompiled headers, whether I use modules or not. Have been doing that for years, so C++20 introducing modules hasn’t been a big change in compilation speeds for me.

One thing to note about using modules, the first time when using a new import the compile time increases slightly as VS compiles the referenced module. Every compile afterwards is speedier because the module is already compiled.

Now, about user created modules the same holds true, as long as the module isn’t modified. First time/make a change takes a wee bit longer.

Forget using the travesty of the MS workaround of std.core. Importing that is as troublesome as precompiled headers in my experience. Just change the C++ stdlib includes to import and you’re good to go.

My projects are usually smallish so any promised advantage modules were supposed to have about being speedier than includes is kinda hard to document. The lengthiest compile time for a single project I can remember was about 45 seconds. Compile times using modules seems to be marginally quicker.

Converting a pre-existing include headers project is either:

1. as simple as changing a couple of keywords in the file. If it’s a header change the file extension. If it’s a source file that accompanies the header change how it is compiles to an internal partition.

2. If the files are code interlocked, one needs another to work, converting to modules can be more time consuming vs. the benefits of using modules. At least that has been my limited experience of trying to convert a pre-modules project to modules.

did you try the derp move of deleting the pch files and letting it rebuild them from scratch? takes a long time, but if they are corrupted, its over. I work on a big project as well and when those go bad (they do in 2019, frequently enough) or the PDB goes bad there is nothing for it but sitting out a longer compile.

All the way back to visual studio 5.0 (I started on 1.0, but that was another story, 5.0 is where I started working with it daily and in depth) the rule of the day was to turn PCH off right away on new projects. It has never worked right, and this is going on 25+ years of having it. Edit-continue PDB is also high risk of failing. Good ideas that sorta work but never quite got a full debugging.

you can try to get it working. One of the failure points is when the files get too big, though. Breaking the code into many small projects that work together to produce a bigger project is a big help.