0

Our large codebase has been updated so that it compiles with both the VS2017/v141 toolset (which we've been building with for several years) and the VS2019/v142 toolset (which we are migrating to). I'm using msbuild at the command line, so I can target either toolset with the exact same source - all source inputs are identical in both cases. Building is either done on my personal Win10 workstation, or one one of our Win7 TeamCity build servers. The result is the same.

The resulting build when targeting v142 produces artifacts that do not run on any of our Windows7 64-bit machines (which we sadly still have many of), failing with error 0xc000007b. Specifically, one of our dlls, which is comes from a CLR enabled C++/CLI project fails to load. Running depends.exe (and the newer open source Dependencies tool) doesn't show anything interesting or suspcious - the artifacts from both builds produce identical reports. When profiling in depends.exe, we see that any exe using the dll from v142 stops immediately after loading it.

Likewise, running procmon shows nothing helpful - identical traces, that obviosuly diverge at some point, but with no hint or clue of any error or problem in the trace from the v142 binary.

The correct vc redistributables are of course installed on the Win7 machines.

All builds work fine on our Win10 machines.

I saw this quesiton, but the given answer does not apply in our case.

Having upgraded to Visual Studio 2019 and the v142 toolset, why does my program no longer run on Windows 7?

I've spent several days trying to get to the bottom of this and have failed. Anyone out there with any similar experiences?

Tom Davies
  • 2,386
  • 3
  • 27
  • 44
  • Have you properly set `#define _WIN32_WINNT 0x0601` in your targetver.h file? See: https://stackoverflow.com/q/63874422/10871073 – Adrian Mole Jun 14 '22 at 11:05
  • hmm, no, we are not defining that anywhere, we are just using it as defined by the SDK version (10.0.16299). But this has been the case for years, and our software runs fine on Win7 when using the v141 toolset rather than the v142. I'll try putting this define into every stdafx and targetver header in the solution and build again. – Tom Davies Jun 14 '22 at 12:59
  • I think there were some significant changes between 141 and 142 - notably, 141 is the last one to explicitly support XP-compatible builds, with the v141_xp toolset. – Adrian Mole Jun 14 '22 at 13:02
  • Thanks for this suggestion - unfortunately it's not solved the problem, but it's another avenue investigated. – Tom Davies Jun 14 '22 at 13:45
  • Just to clarify: All these machines are Windows 7 Service Pack 1 and not RTM? You should explicitly set ``_WIN32_WINNT`` to ``0x0601`` if you want Windows 7 compatibility. Also, *which* version of VS 2019 are you using? – Chuck Walbourn Jun 14 '22 at 19:09
  • Win7 SP1 , yes. The installed version of VS2019 is 16.11.14. MsBuild is v 16.11.2+f3225964. – Tom Davies Jun 15 '22 at 07:23

0 Answers0