Compiled .EXE can't find mex, but I can see it in the CTF archive!

I've compiled an application, which contains a mex file called iprodFloat.mexw32. On the machine where I compile, it runs fine. I'll footnote here that this machine is 64-bit, running Windows 7, but I compiled the application within a 32-bit MATLAB installation.

On the target 32-bit machine, the application launches successfully, but quits with an error part way through, saying that it cannot find iprodFloat.mexw32. However, the error message gives the full path to the ctf archive folder where it failed to find the file, and when I go there, I can see the mex file sitting there in plain view. Obviously, I'm at a loss as to why the application cannot find it!

To double check, I deleted the CTF archive on the target machine and ran the .exe again. This regenerated the CTF archive, again containing iprodFloat.mexw32, but again the .exe quit with the same error.

The only thing that looks a bit suspicious to me is that the CTF archive also contains a file called iprodFloat.mexw32.auth. I'm wondering what the purpose of such a file is, and if it restricts access permission to the file somehow.

Would be grateful for any insights!

[George]

Hi Matt, I do not know what the iprodFloat.mexw32.auth file is or does.

I think that the user running the exe must have read & write permission to the directory where iprodFloat.mexw32 exists. Is that condition met on the machine where it fails?

[Matt J]

Hi George, since the application partially runs, and uses other files in that directory, that seems to suggest that permissions to access the directory are present. Also, the .exe creates that directory. It doesn't seem likely that it would create it, but then not be able to access it.

Answer 1

[Image Analyst]

What platform is this on? Windows 7? If so, the exe unpacks the actual executable to some hidden folder in the c:\users\Matt\blah blah blah folder. Put this line in your startup code to see where it actually lives:

ctfroot

It may not be where you thought it was. So if it is in your Users folder, permissions would not be an issue. UNLESS you did a cd() in your code - which is usually not advised. Is there a cd anywhere in your code?

Have you also gone through the items in the FAQ: http://matlab.wikia.com/wiki/FAQ#My_standalone_executable_won.27t_run_on_the_target_computer._What_can_I_try.3F

Is the application that tries to use your mex file a MATLAB-compiled executable, or some other program, like one created in Visual Studio?

[Matt J]

It's Windows 7. The mex is used by a MATLAB-compiled executable. There is no call to cd() that I can find.

I don't see how it can be an issue either of where things get unpacked or the contents of that directory. The error message told us the path where the executable is searching for and failing to find the mex. Nevertheless, directly inspecting that directory does show that the mex is in there. Also, we deleted that directory and running the .exe regenerated it at the same location.

In light of this, I also don't see how the FAQ items can be applicable. They all talk about verifying that the necessary dependent files were embedded in the .exe. We were able to verify that the file in question was in there by direct inspection.

[Image Analyst]

Well the program can bomb if it can't find dependent files even though the main one is there. Can you tell me that you ran dependency walker on your mex file and it came up with no "red" (missing) items?

Do you have a MCR_CACHE_ROOT environment variable defined? To help with debugging, you can define it as . (dot) so that it unpacks stuff as a subfolder of where the exe archive lives instead of in that secret hidden folder.

Would this be worth a try?

[Matt J]

Well, I guess it can't hurt to check. But wouldn't a missing dependent file be mentioned by name in the error messages? Why would only the mex that calls it be mentioned?

[Image Analyst]

If a DLL or mex is missing a dependent file, you won't know about it since it will only mention the main one. Well it might if it uses late binding but that's rarely the case in situations I've seen - they're almost always early binding. In other words, it checks in advance for all the dependent files that it may possibly need even if it never actually does call them all. With late binding, it doesn't check for a dependent file until the time when it actually needs to call that file.

[Matt J]

I overlooked Item 7 in the FAQ. It was missing the MS Visual C Redistributable.

For whatever reason, though, this is only an issue when compiling under a 32-bit MATLAB version. When I compile under 64-bit, there's no problem.