Matlab MDCS with loadlibrary, Module not found...

I have been having trouble loading a dll into each worker of a matlab cluster. I have been using a thunk and prototype file and have tried placing the thunk file into two places, a share drive accessible by all the nodes and a local directory in a matching location on all the nodes. I made sure to properly update the prototype file. I still get the dreaded "Error using loadlibrary: The specified module was not found" error.

To test that the thunk file is accessible from each node, I ran fopen on each worker, and got no -1 answers. like this:

spmd
  fopen('*** path to thunkfile .dll ***')
end

So I know that my problem is not

1. Permissions, because I was able to access the thunk file using fopen.
2. Non-MDCS problem, because I can run this code no problem on a local cluster. With thunk file in a local location and with the thunk file on the share drive.
3. Lacking a supported compiler, because I'm using a thunk and prototype file.
4. The prototype file pointing to the wrong thunk file location, because I used disp() in it to check as I was running this.

Does anyone have any ideas of other stuff to try?

Answer 1

[Edric Ellis]

I suspect that even if the actual .dll file is correctly available on the workers, perhaps some dependent libraries are not being found. (I think this can result in the same error). To diagnose this sort of thing, I would try "depends.exe".

One other thing to remember though is that on Windows, MJS worker processes run in a service context, and in particular they can't see mapped drive letters.

[Nathan Ellingson]

It only seems to depend on two DLL's that are both in the system32 directory. I hope that it can see those DLL's.

Also another weird detail, I was able to load the dll's when I had the client (instance of matlab) running on the head node... but only for the workers running on the head node.

[Philip Borghesani]

You need to check both the thunk file and the dll you are trying to load. Any compiler run time libraries for both the thunk file and for the actual dll need to be installed on all worker machines. If the dll was built debug then the compiler may need to be installed on all machines because installable Microsoft run-time libraries do not support debug dlls.

Depends is the tool for the job.

[Nathan Ellingson]

This could definitely be my problem...

[Nathan Ellingson]

No luck, checked with Depends.exe on both the actual dll and the thunk file, and I didn't see any libraries that would indicate that the VS Compiler was run in debug mode.

For the DLL i'd like to run I saw only two direct dependencies: KERNAL32.DLL and IMAGEHLP.DLL (Both are system32 DLL's)

For the Thunk file the only direct dependancy was KERNAL32.DLL.

I was hoping that this was the problem, because it's actually happened to me before in a different context and was big headache with a really simple solution.

[Nathan Ellingson]

So, I solved this by recompiling the thunk file with MinGW, instead of Visual Studio. I pretty sure that the old thunk file did not depend on any VS development libraries, based on depends.exe so I'm not sure why this made a difference, but it's working now!