CODEWITHSUNDEEP
c++visual-c++
Dan
Dan

Reputation: 107

Windows 10 app with dynamically linked VC++ does not start even after installation of VC++ 2017 redistributable

We're currently beta testing a Windows application which is built with the latest Visual Studio in C++ and runs on Windows 10. The application dynamically links the VC++ libraries (static linkage is not an option for us).

On 75% of our testers' machines (including all our dev machines), the application works out of the box after installing, but with some others it does not start and fails (presumably) during the process of loading dynamic system libraries (since it does not trigger any kind of exception that would write a minidump as with runtime errors).

  1. Some of these users have had errors about missing runtime dlls which were solved after installing the latest VC++ 2017 redistributable, however the application still would not run.
  2. One user has also checked the library dependencies with the Dependencies tool (https://github.com/lucasg/Dependencies), but his results show nothing strange - there is no obvious difference between the output on a working machine and on his own. There are a few question marks (see screenshot: missing modules as shown in Dependencies) next to some UCRT subdependencies but they are there on working machines as well so I presume they are false positives.
  3. I've also tried to deploy the relevant 40 something UCRT and VC++ dlls as an app local deploy next to the executable but it still wouldn't open on the affected machines (I might have missed some relevant ones, or they were still referenced from the System32 folder)

How would you debug such a problem, providing we cannot reproduce it locally (it works out of the box on two completely new devices with a fresh Windows 10 install and without a build environment) and there is a very little information on what might be going wrong with the library calls?

Upvotes: 2

Views: 143

Answers (1)

rustyx
rustyx

Reputation: 85286

c000001d is illegal instruction exception code.

Either you are targeting instruction sets like AVX2 or SSE4.1 which the customer CPU doesn't support, or the executable is corrupted (e.g. downloaded in text mode instead of binary mode).

For best possible portability do not specify /arch:AVX or /arch:AVX2 when compiling with VC++. The compiler will then target the base instruction set available on the given architecture (x86 or x86_64 with SSE2).

Upvotes: 2

Related Questions