Gentlemen, thanks for the response.
I have fixed the issue. 🙂
After trying many things, I came across a webpage
https://area.autodesk.com/blogs/max-station/n88_if_you_can_run_3ds_max_only_once/
In which they refererred to another page:
http://download.autodesk.com/global/docs/3dsmaxsdk2012/en_us/index.html?url=files/GUID-0C178DAC-7F0C...
There they also describe a 126 error:
---
Load Order Dependencies between Plug-ins
The deferred plug-in DLLs are loaded when a certain user action requires them to be present. Because the sequence of user actions is not always predictable, the order in which deferred plug-in DLLs are loaded by 3ds Max will not be deterministic. In general, Plug-in DLL A has a load order dependency on plug-in DLL B if B needs to be loaded in 3ds Max's address space before A. If plug-in DLL A calls a function exported from plug-in DLL B, a load order dependency will exist between the two plug-in DLLs.
If the plug-in DLL B is defer loaded:
Plug-in DLL A may fail to be loaded by the operating system's loader. In thiscase error 126 (The specified module could not be found) is displayed by the operating system. This is the case if plug-in DLL A links against plug-in DLL B.
- A run-time error may occur if plug-in DLL A tries to acquire the address of a function exported by plug-in DLL B (with a call to WINAPI GetProcAddress()) and call that function.
The solution to this problem is to eliminate the load order dependency between the two plug-in DLLs by:
- Moving the functionality that the plug-in DLL A (and possibly plug-in DLL B) relies on into a new DLL C that is not a plug-in and that any plug-in DLLs can either link against or load at runtime.
- The DLL containing the common functionality should not be delay loaded if it exposes core interfaces to MAXScript. The delay loading mechanism may result in the core interface not being properly registered and 3ds Max may crash when client code requests such an interface.
- Exposing the functionality plug-in DLL A relies on as a core interface (an object that derives from FPStaticInterface and is created with the FP_CORE flag). Plug-in DLLs that expose core interfaces are guaranteed to be loaded on demand, when client code acquires the core interface they expose.
---
This led me to check our 2 plugins.
Both have this:
--
// The plug-in opts out from 3ds Max’s defer loading mechanism,
// i.e. it’s always loaded when 3ds Max starts up.
__declspec( dllexport ) ULONG CanAutoDefer()
{
return FALSE;
}--
However, only one had:
--
You will also need to add this line to the *.DEF file. Example:
CanAutoDefer @5
--
The plugin that did not have this line in the *.def file was not the plugin that failed to load though... But when I corrected this, and added the given line to that plugin so they are both the same. The problem was gone! So apparently max2018 does something different wrt the loading of plugins than max2020 and up.
