How to deal with precompiled headers randomly becoming corrupted on a cancelled build?

Question

I use Visual C++ 2012 with a project that makes a heavy use of precompiled headers. So heavy that the infamous /Zm switch is in use.

When I cancel a build in progress, I sometimes get this error on the next build:

error C1852: 'foo.pch' is not a valid precompiled header file

Nine times out of ten, things will go smoothly, but when this happens I have to find the .pch and delete it manually before restarting the build.

That annoys me a bit. Is there a way to prevent this from happening? A patch from Microsoft? Or a way to force Visual to delete the .pch and restart the build automatically when the issue occurs? Or some other solution I didn't think about?

EDIT: Here's the version of Visual I'm running:

Microsoft Visual Studio Professional 2012
Version 11.0.61030.00 Update 4

Answer 1

I followed rockeye's suggestion of trying to find a pattern in these corrupted files. Turns out it's very simple: valid files start with a VCPCH0 header, corrupted files don't.

A simple C# program run as a Pre-Build Event of the failing project(s) and deleting the corrupted files solves the issue. If anyone's interested, the source is right here.

Answer 2

This is a pure conjecture, as I did not run into this issue.

Try to find out how Visual detect a .pch file is corrupted (i.e. empty file, file not correctly ended, ...). If it follow a clear pattern, write a pre-build script that parse all .pch and delete corrupted ones.

Answer 3

I would create a script that would attempt to recompile the stdafx.cpp file, but this time using the PCH instead of generating it. I.e. the expected outcome is the successful compilation of an empty file. If this fails, delete the PCH. Now run this script as a pre-build step.

It sounds fairly expensive, but it's very reliable. Any problem loading the PCH causes its regeneration, even compiler upgrades. Also, your PCH is now in file cache, which means the actual use is slightly cheaper.

This might be implemented as an NMAKE build script with somewhat unusual rules.