1

I'm facing a weird problem. Using cmake-3.24.2 I have built a windows application (windows 10) with c++20, in release mode. (Visual Studio 2019, x64) The application runs fine on the machine it was built.

When deploying the same application on another windows machine, it was failing to start showing an error about missing ucrtbased.dll (and subsequent vcrt debug dlls). I'm actually confused why a release build looking for a debug dll. I used dependency explorer to see if the application was linked to any debug dll and I could not find any.

Google search showed the ucrtbased.dll is part of windows sdk. The windows sdk was not installed on the target machine. Is the windows sdk needed to run the application (I thought vcruntime was sufficient).

Also the same code works fine if I used c++17 standard and deployed on the target machine. I'm wondering if there's something I'm missing with c++20.

Surya
  • 1,139
  • 1
  • 11
  • 30
  • As you already noted, ucrtbased.dll is the debug version. There must be configuration error in your cmake files which accidentally links the debug instead of the release runtime libraries. Check the commandline or created project: Does it include the `/MT`/`/MD` (release) or `/MTd`/`MDd` (debug) switch? Regarding the failure of dependency walker, it is hard to guess without more details, but maybe it is not picking up the debug dependencies because it is rather outdated (see e.g. [this](https://ofekshilon.com/2016/03/27/on-api-ms-win-xxxxx-dll-and-other-dependency-walker-glitches/) blog post). – Sedenion Oct 12 '22 at 17:32
  • I looked at the entire command log and I could verify its /MD not /MDd – Surya Oct 12 '22 at 17:54
  • Also, when running the same executable locally, it works fine even when ucrtbased.dll is not in path. Which is strange. I checked the compiler flags and /NDEBUG is defined, which is fine. The only place where /DEBUG is defined is on linker flags (to create pdb file). Will that have any affect on dlls the executable is looking for ? – Surya Oct 13 '22 at 04:58
  • I think I have found out the culprit dll. Following the answer from [here](https://stackoverflow.com/a/31803638/234542) – Surya Oct 13 '22 at 09:42

1 Answers1

1

The solution is mentioned here. Ran dumpbin on every dll my executable is dependent on and found out the culprit

Surya
  • 1,139
  • 1
  • 11
  • 30