DLL freezes on latest 9.0.7 release

[zactrack-dev]

Describe the bug Buildling a Lib file on Windows and creating a subsequent DLL from a Cmake project, that statically links that Lib, a process that is loading the DLL gets stuck without output.

To Reproduce Steps to reproduce the behavior:

1. Build the Lib on Windows using the BAT script: "buildLib_Win.bat Release MD MZ false"
2. Create a simple Cmake Project and link the Lib (and add includes)
3. Write a small test routine, e.g. calling the QueryLocalServices() in the main() method
4. Build an EXE out of it -> it works
5. Build a DLL that exports e.g. said QueryLocalServices() method -> any process loading that DLL will freeze

Expected behavior DLL shall load without issue. No problems with version 9.0.6

Desktop (please complete the following information):

• OS: Windows 11
• Visual Studio 2022 Community

Additional context I was able to boil down the problem to the changes made in CMVRxchangeService.h/.cpp, which seem to fix stability issues when repeatedly creating and stopping local services. When building the EXE as mentioned above, it works as expected and the stability issues are gone. I am lacking knowledge of the mechanics behind DLLs. Why are processes freezing already at DLL loading stage without calling any code from it?

[zactrack-dev]

Might be connected to this: LINK

[stephezapo]

Any updates on this? I was trying to fix it myself, because it looks easy on the first glance, but no luck so far :-(

[moritzstaffel]

We are looking into this and there will be a fix soon.

[stephezapo]

Hello! Any news on this? I see that there were 2 releases recently without changes on the xchange side. Is the problem reproducable on your side?

[pwinkler-ds]

Hello @zactrack-dev,

I was not able to reproduce this issue with v9.0.7, can you share the zipped projectfiles here so we can test it with the same setup.

regards, Patrick

[stephezapo]

Hello @pwinkler-ds ! Thanks a lot for getting back on this. I sent a mail to @moritzstaffel with a zipped cmake project to reproduce the issue using the latest 9.0.11

Kind regards, Stephan

[pwinkler-ds]

@stephezapo Thanks for your mail.

Using a shared pointer for asio:deadlock solves the problem on my side, we will update this soon.

But it is not recommended to define objs or in this case initialise a VComPointer in global space especially in DLL's.

The easiest solution is to put the global IMVRxchangeServicePtr pointer (mvr-gdtf-utils.cpp) into a wrapper so it does not get initialized before the dll loading lock is released.

IMVRxchangeServicePtr getServicePtr()
{
    static VectorworksMVR::IMVRxchangeServicePtr service(VectorworksMVR::IID_IMVRxchangeService); 
    return service;
}

// Example call
if (getServicePtr()->QueryLocalServices(count) != 0)

I am lacking knowledge of the mechanics behind DLLs. Why are processes freezing already at DLL loading stage without calling any code from it?

Global scope has to be executed before DllMain gets called to make sure that gloabls are available inside there.

[stephezapo]

@pwinkler-ds Thanks a lot for the helpful hint and sorry for the delay!