vcruntime140.dll sometimes missing from top level

[stevenbronson-wk]

Sometimes vcruntime140.dll isn't copied to the top level of our Windows builds even though we pass include_msvcr.

_post_copy_hook calls _pre_copy_hook (which copies vcruntime to lib/) and then _copy_file with the new target returned from _pre_copy_hook (top level). However, _copy_file itself calls _pre_copy_hook, which changes the target from top level to lib/ again because vcruntime is in runtime_files but no longer in runtime_files_to_dup.

So I think we get a top level vcruntime140.dll when _freeze_executable finds it directly and passes it to _copy_top_dependency, but not when it's found as a dependency of another DLL (e.g. vcruntime140_1.dll) and _post_copy_hook tries to copy it.

I think it'd be difficult to reliably reproduce this, but if my explanation doesn't make sense and you need an example, let me know.

Windows (64 bit)
cx_Freeze 6.13.1
Python 3.10.9

[martinmiglio]

I'm running into a very similar issue.

When running my cx_freeze script directly I am shown the dll is copied correctly:

copying C:\Python311\VCRUNTIME140.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140.dll
copying C:\Python311\VCRUNTIME140.dll -> D:\XXX\build\exe.win-amd64-3.11\vcruntime140.dll
...
copying C:\Python311\vcruntime140_1.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140_1.dll
copying C:\Python311\VCRUNTIME140.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140.dll

When running the build script as part of a npm script for packaging my app, I am shown that the dll is copied to the build\exe.XX\lib directory (twice?) but doesn't get copied to the top-level build\exe.XX\ directory when the build process is done:

copying C:\Python311\vcruntime140_1.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140_1.dll
...
copying C:\Python311\VCRUNTIME140.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140.dll
copying C:\Python311\VCRUNTIME140.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140.dll

I might have to include the dll manually for later in my packaging process as a work around but I really don't want to have to do that if it is an option available in cx_freeze.

Windows 11 64bit
cx_freeze 6.13.1
python 3.11.0

[marcelotduarte]

I cannot reproduce this, but I'll try to change or force the copy to the correct location.
@marmig0404 What is the line before the copy of vcruntime140.dll? Does it, in both cases, your app?
Can you check with 6.14.2?

[martinmiglio]

from that same log (cx-freeze 6.13.1):

...
running build_exe
creating directory D:\XXX\build\exe.win-amd64-3.11\lib
copying C:\XXX\Python\3.11.1\x64\vcruntime140_1.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140_1.dll
copying C:\Program Files\PowerShell\7\api-ms-win-crt-heap-l1-1-0.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\api-ms-win-crt-heap-l1-1-0.dll
copying C:\XXX\Python\3.11.1\x64\VCRUNTIME140.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140.dll
copying C:\XXX\Python\3.11.1\x64\VCRUNTIME140.dll -> D:\XXX\build\exe.win-amd64-3.11\lib\vcruntime140.dll
...

Running on 6.14.2, it has been copying the dlls consistently so far.

[marcelotduarte]

Is the .exe copied after these four lines? It should be the first.

Running on 6.14.2, it has been copying the dlls consistently so far.

Do you mean 6.13.1 has the problem and 6.14.2 doesn't?

[jhoekx]

We have not yet built our MSI with 6.14.2. But we still had this problem on 6.14.1 (it does not look like the commits in between would have any effect on this).

Here are the last lines of a "failed" build:

 copying build\exe.win-amd64-3.10\Timeseer-example.toml -> build\bdist.win-amd64\msi
copying build\exe.win-amd64-3.10\timeseer-reverse-proxy.exe -> build\bdist.win-amd64\msi
copying build\exe.win-amd64-3.10\timeseer-service.exe -> build\bdist.win-amd64\msi
copying build\exe.win-amd64-3.10\timeseer.exe -> build\bdist.win-amd64\msi
creating dist

Here's a rebuild of the same commit:

 copying build\exe.win-amd64-3.10\Timeseer-example.toml -> build\bdist.win-amd64\msi
copying build\exe.win-amd64-3.10\timeseer-reverse-proxy.exe -> build\bdist.win-amd64\msi
copying build\exe.win-amd64-3.10\timeseer-service.exe -> build\bdist.win-amd64\msi
copying build\exe.win-amd64-3.10\timeseer.exe -> build\bdist.win-amd64\msi
copying build\exe.win-amd64-3.10\vcruntime140.dll -> build\bdist.win-amd64\msi
creating dist

Chances are around 50-50 to get a working build.

[martinmiglio]

Do you mean 6.13.1 has the problem and 6.14.2 doesn't?

I've only had the chance to test 6.14.2 on a few builds and it has worked, but i don't think that confirms this version fixed the issue as @jhoekx mentions.

[marcelotduarte]

Can you test my patch?
pip install --upgrade --pre --extra-index-url https://marcelotduarte.github.io/packages/ cx_Freeze

[marcelotduarte]

@stevenbronson-wk @jhoekx @marmig0404 ping

[jhoekx]

I tried 4 builds this morning with the patched version. All of them included the vcruntime140.dll (and the other DLLs are now newly included at the top level). They also produced a working application.

To be fair, our last 3 builds on 6.14.2 last week were also 'good'.

[stevenbronson-wk]

In freezer.py, I replaced

for source in dependent_files:

with one of these

for source in sorted(dependent_files, key=lambda p:(p.name.casefold() != 'vcruntime140.dll', p)):
for source in sorted(dependent_files, key=lambda p:(p.name.casefold() != 'vcruntime140_1.dll', p)):

6.14.2 works if vcruntime140.dll is first and doesn't if vcruntime140_1.dll is first.
Prerelease 6.15.0.dev0 works in both cases.

[marcelotduarte]

https://github.com/marcelotduarte/cx_Freeze/releases/tag/6.14.3