Announcement

Collapse
No announcement yet.

2020 SDK crash when deferring VRay.dll

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 2020 SDK crash when deferring VRay.dll

    I have a plugin that has optional VRay integration. Currently I have DelayLoad set in my project for: VRENDER2020.DLR; VRAY2020.DLL; VRAY.DLL....the idea being that if someone doesn't use VRay, my plugin will still load since the VRay libraries won't be queried until VRay itself queries my plugin. This was working fine in 3dsmax 2017/2018/2019.

    However, it's broken in 2020.

    I have no static objects defined that are dependent on any of the VRay libraries (that I'm aware of), however...when my plugin is initializing in max 2020 (when it is first loaded with 3dsmax during the splash screen) it will crash and return an "ERROR_MOD_NOT_FOUND" error inside delayhlp.cpp. The autos generated imply that "vmalloc" was called somewhere and thus an attempt to find "Vray.dll" fails (which causes the crash).

    Since I don't see anything in my code calling vmalloc, it leads me to believe there is some static object within the updated vray libs doing it or something. In fact, I commented out all VRay-relevant parts of my code, and the crash still occurs.

    Attached is a screencap of the autos. The call stack itself doesn't return any helpful information (the only module listed is delayhlp.cpp in which the dll error occurs).

    From my testing, it seems the crash occurs once I include vutils_s.lib in my build.

  • #2
    Hi there, so, there's the file "SDK/valloc_impl/vallocstub.cpp" which should be used if you don't want your or the v-ray static libraries' allocations to pass through to V-Ray. Can you try including it as a translation unit in your project?

    Comment


    • #3
      That was it! Thank you. Funny, I searched the VRay SDK for all mentions of vmalloc ("m") to see if I could find where the problem was coming from, but missed the comment at the top of that stub explaining that it should be used to prevent calls to "valloc" (no "m"). I blame that pesky "m"!

      Comment


      • #4
        Glad it worked! Yeah, I decided to write "valloc" there instead of "vmalloc" as it prevents calls to all the allocation functions and not just vmalloc.

        Comment

        Working...
        X