11

I get this error message from time to time (not every time) I compile (EDIT: sorry, I didn't make myself clear here: I actually meant "rebuild") my mixed-mode project. And Visual Studio tells me to "recompile with a command line option of '-Zm114' or greater". In principle no problem, I just do as VS tells me.

But currently, there are two problems with this:

  1. Why does it not occur every time I do a rebuild? If I understand correctly, the compiler ran out of memory while compiling my project. So if I do a rebuild, which cleans all prior work, shouldn't it run out of memory the next time too, if I don't change anything?

  2. To be on the safe side, I already have specified a value of 120 for Zm (ie Zm120) in all configurations of this project. Why do I get an error message with this lower value? Or is the suggested value of 114 just a wild guess of VS?

derpirscher
  • 14,418
  • 3
  • 18
  • 35
  • A PCH file should be generated only once. If you run into this error then you changed a .h file that's included in the PCH, non-zero odds that such a change triggers the error again of course. Ultimately this is likely to be a bad practice and you should trim the PCH to only use headers that never change. Windows.h is good, a library like Boost is good. Something like string.h is too small to bother. That doesn't trigger C3859. – Hans Passant Jul 20 '16 at 11:57
  • @HansPassant Yes, I understand the concept of precompiled headers. But a rebuild should also rebuild the precompiled headers. Thus, if I change nothing at all (no file, no compiler options) and just hit "rebuild" the error should occur again, shouldn't it? – derpirscher Jul 20 '16 at 12:04
  • As to the `/Zm` part of the question, according to [here](https://devblogs.microsoft.com/cppblog/precompiled-header-pch-issues-and-recommendations/) (search for Ignoring the /Zm flag), beginning with MSVS 2015 the Zm flag should not be used anymore (there are exceptions of course) and the value reported by fatal error C3859 should be ignored. – Brandlingo Jun 14 '19 at 09:30
  • 1
    +1 on the don't use `/Zm` comment. we just fixed out of memory problems with our projects by removing these options. it seems this may not work well with `x64` – Chris Guzak Jul 06 '19 at 02:07
  • 1
    I enountered this error for the first time today when I decided to build my DEBUG x64 project with the new "Clang-tidy" code analysis setting. – Andrew Truckle Jan 17 '21 at 14:37

5 Answers5

14

I know this is old but I ended up here so I might as well answer.

There is a great article about PCH problems here.

1) Why does it not occur every time I do a rebuild?
This is a bit complex to answer surely. Since it is not happening every time, it could be several issues. It is most likely due to memory allocation. From the article :

  • Fragmentation of the virtual memory address range(s) required by the PCH before CL.EXE is able to load it into memory.
  • Failure of the Windows OS under heavy loads to increase the pagefile size within a certain time threshold.

It could also be a Pagefile size problem (most likely on Virtual machines) but I believe you would have a message similar to this :

c1xx : error C3859: Failed to create virtual memory for PCH [...Project.vcxproj] c1xx: note: the system returned code 1455: The paging file is too small for this operation to complete

2) Why do I get an error message with this lower value? (Zm114 instead of Zm120)
Make sure that the Zm120 modifications handle all the build configurations (Release|Debug) and Platform (x86|x64).

It could also help to set PreferredToolArchtecture to x64:

If you’re using MSBuild from the command line you can pass /p:PreferredToolArchtecture=x64 to MSBuild. If you’re building with MSBuild from within Visual Studio, you can edit your .vcxproj file to include a PropertyGroup containing this property.

This one is easily overlook, but those kind of problem also happen when the precompiled header is just too big. Doing a little cleanup might be a good idea as well.

Scott
  • 383
  • 3
  • 10
2

I was running into this compiling a large code base on a local VM. Tried upping the page file size etc and didn't work. The only thing that worked in my case was to disable dynamic memory in the Hyper-V VM setting and give the VM more RAM, 8GB -> 16GB.

Apparently VS allocates it's memory up-front so it only uses the initial value given to the VM and won't trigger any dynamic memory changes.

Geordie
  • 1,920
  • 2
  • 24
  • 34
2

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:

CJCombrink
  • 3,738
  • 1
  • 22
  • 38
  • I hit this too, and spent waaaay too long trying to figure out what was going on with my compiler settings, toolchain, build options. In the end, of course, it was WinRM. If I could upvote more than once I would – Adam Comerford Feb 19 '21 at 16:42
0

Just chiming in with what the solution ended up being for me. It seems that Visual Studio was trying to compile my program for multiple architectures, despite me thinking I had removed the profiles, there were a bunch of bogus entries in the configuration manager to build in x86 mode. These were useless to me since I want to build in x64 only. After removing those entries, the program compiled again and this error was gone. Hope it helps someone.

Cam
  • 11
  • 2
0

Yet another cause of this problem. I'm not crystal clear how the project got into this condition, but it was trying to use PCH files, had the "Precompiled Header File" option set to pch.h, but the "Precompiled Header Output" option just below was empty.

Not really surprisingly, but Visual Studio got its nose very badly out of joint about that, in particular throwing numerous C3859 errors during the build.

Sorting out the project configuration to "Inherit" this value fixed it right up.

dgnuff
  • 3,195
  • 2
  • 18
  • 32