Project Tool freeze after win10 update



  • Hello,

    Our build server is freezing when executing after a windows update.

    We're using the September 6th, 2018 Project Tool.
    winver.exe shows (OS Build 17763.529)

    Can you confirm if the tool works with that windows version?
    Is there any new version of the tool available?

    [18:46:33][CustomBuild] Project Tool ["D:/TeamCity/....../Maxon/Cinema4D/SDK/R20.026\..\..\ProjectTool\cinema4d_r20_project_tool_20180906\kernel_app_64bit.exe"]
    [21:34:51][Step 3/10] The build Cinema4D - Windows #1820.bbd6c7f0a272% {buildId=133757} has been running for more than 180 minutes. Terminating...
    [21:34:51][Step 3/10] Execution timeout
    


  • Hi @rsodre, thanks for reaching out us.

    With regard to your issue, I'm almost everyday using the Project Tool revision you've pointed out with that Windows OS revision level and have experienced in the last week not a single issue.

    Is there any other information that can be generated in that time span (180') maybe raising the verbosity level of your tool-chain script?

    Best, Riccardo



  • @r_gigante Thanks for the tips, Riccardo.

    Investigating more we discovered that the update removed some dlls.
    We managed to find the new ones and fix the issue.



  • @r_gigante , some details of what happened here, that looks like a dependency issue on kernel_app_64bit.exe...

    When you just start kernel_app_64bit.exe from External\Maxon\Cinema4D\ProjectTool\cinema4d_r20_project_tool_20180906 on the agent, you get an error "missing libmmd.dll"
    And Dependency walker shows that indeed the .exe depends on that dll and it cannot be found
    It looks like this dll was installed by someone on the agent, but the 1809 update removed it (Win10 updates are known for removing applications they consider "incompatible")
    I opened kernel_app_64bit.exe in a dependency walker on my machine and found that I get that libmmd.dll from some common Intel installation, probably of some drivers
    Then I wondered how Maxon expected the tool to run when it depends on a .dll that is not commonly included in Windows, and indeed I found that the dll is placed in resource\libs\win64 under the .exe
    But for some reason the .exe won't pick the .dll from that directory, and the fact that it happens to run on some systems is that they already have the dll installed by another app

    I now copied libmmd.dll from resource\libs\win64 to the directory of the .exe and it ran fine from Windows Explorer, let see if the TC build will work. The TC build succeeded

    I think MAXON should check why kernel_app_64bit.exe doesn't pick the dll from resource\libs\win64
    Now we have to move .dll to the directory of the .exe in our Svn repository as well (which is not how it is distributed by Maxon), to make fresh installs work too



  • Hello,

    the libmmd.dll is part of the Intel runtime redistributables. This DLL is typically installed on a system by the Cinema 4D installer.

    The proper redistributables should be these: https://software.intel.com/sites/default/files/managed/d6/c2/ww_icl_redist_msi_2019.2.190.zip (But I haven't tested that).

    Alternatively one can - as you have discovered - move the DLLs from the libs/win64 folder to the executable folder.

    best wishes,
    Sebastian



  • Thanks a lot @rsodre for your investigations! We are trying to build our plugins using Azure Pipelines and I had the same issue (project tool not executing correctly) there. Copying the DLLs into the executable folder solved the issue :)

    Unfortunately the tool now runs forever, I'll have to investigate myself a bit more why. If you got some more hints, let me know!



  • Okay, my guess is that the Windows tool requires the user to press ENTER when the tool has finished its work. Is this correct? It would explain why the tool runs forever on the build server.

    And if it is the reason: Would it be possible to remove this behaviour from the tool? As I see it it is not really uncommon to run the project tool automatically rather than being executed by a human user.



  • Hello,

    you can set the command line argument

    g_disableConsoleOutput=true

    to hide any output or interaction with the Project Tool.

    See Project Tool.

    For questions no longer related to the threads original topic, please open a new thread. Thanks.

    best wishes,
    Sebastian



  • I see, thanks for the quick reply. I will try it and if doesn't work I'll open a new thread about the topic.

    Cheers
    Christian


Log in to reply