errors in making standalone program using matlab 2013b

Hi,

I was using matlab 2013b and Matlab Compiler Runtime 2013b to make a standalone program. Matlab can successfully generate an executable but when I run it I got "The procedure entry point ?deallocate_via_handler_v3@internal@tbb@@YAXPAX@Z could not be located in the dynamic link library tbb.dll." I tried different codes and got the same error. Any thoughts on the tbb.dll error?

My operating system is Windows 7 professional. I tried both 32 bit and 64 bit matlab and MCR but none of them worked out.

Thanks in advance, Yubo

[Yubo]

I tried the same code on a 32-bit XP machine with matlab 2009 and MCR, it does work so there should be no problem with the code itself.

Answer 1

[Peter]

Hi Yubo, I encountered the same problem as you described. Yust copy the tbb.dll (C:\Program Files\MATLAB\R2013b\bin\win64\tbb.dll) to the folder where your executable is and the problem is solved.

Kind regards,

Peter

[Yubo]

Thanks for your input peter. Someone suggested the same solution and that did work out.

Yubo

[Image Analyst]

Yeah, that was me, as you'll see if you look at my Answer/solution below.

Answer 2

[Martijn]

Errors like the one shown above occur when an application encounters a different tbb.dll version than expected. So the important question to ask here is why does an application (or a MATLAB Compiler Standalone in particular here) encounter a different tbb.dll version than expected?

To be able to answer this it is first important to know how the Dynamic-Link Library Search Order works. Basically whenever an application tries to load a DLL, Windows will look for this DLL in the following locations in the following order (I only list the locations relevant for this discussion):

1. The directory from which the application loaded.
2. The Windows\System32 directory.
3. The Windows directory.
4. The current directory.
5. Directories on the PATH environment variable.

Now both MATLAB and the MCR "try to be nice". They include tbb.dll in their bin\$arch directories which by default is not added to PATH and which obviously is also not the Windows(\System32) directory. So basically they cannot influence other applications.

Further when you run normal MATLAB through bin\matlab.exe this will underneath run bin\$arch\matlab.exe. So for MATLAB itself, tbb.dll is immediately found on "1. The directory from which the application (bin\$arch\matlab.exe) is loaded". So here nothing can go wrong.

For a MATLAB Compiler Standalone however this story is different. A standalone basically starts with loading mclmcrrtM_N.dll and this should be found on "5. Directories on the PATH" (MCR\runtime\$arch directory in this case). It then determines where bin\$arch is (relative to the location of mclmcrrtM_N.dll) and it adds this directory to the front of PATH (for the current application only, not the system wide setting). Then at a later point when tbb.dll gets loaded this is resolved in the following way:

1. "The directory from which the application loaded." for a standalone this is the location containing yourStandalone.exe (which is not the MCR\bin\$arch directory). So by default tbb.dll is not found here. As suggested by Peter though you can place a manual copy here of the right version (the one included with MATLAB/MCR) to work around issues which could occur in the further steps.
2. "The Windows\System32 directory." For things to work correctly tbb.dll should not be found here. Some other ("less nice" in terms of not trying to influence other applications) application may have decided to place a tbb.dll here though. In that case your standalone will get to see this tbb.dll. If that is an different version this can lead to the errors. (Note the emphasis on if, only if this is a different version an error can occur which may explain why things worked fine in R2013b but R2014a needed a workaround for "Image Analyst"). If you encounter an incorrect tbb.dll here you can consider removing this DLL such that the search continuous below or as mentioned under 1 place a correct copy next to the standalone.exe to prevent ever even getting to this point.
3. The Windows directory. Basically the same story as the previous point. tbb.dll should not be found here but it could happen.
4. "The current directory" often equal to "The directory from which the application loaded." but not necessarily so. This one hardly ever causes an issue though. But again tbb.dll should normally not be found here.
5. "Directories on the PATH environment variable." now here tbb.dll should be found, more specifically in MCR\bin\$arch which the standalone added to its PATH at startup. (Note that PATH really is the last thing which is looked at which may explain why Ralph's approach did not work, he probably encountered a tbb.dll in Windows\System32).

[Image Analyst]

Nice thorough explanation. I wish I knew how the extra, rogue tbb.dll got there though.

[Art Kotz]

Agreed! Very helpful. I just spent an hour working with a user to figure out why my deployed app (or any other Matlab app) wouldn't run. Then I found this thread. He had a Labview app installed. Putting tbb.dll in the executable directory solved his problem.

I anticipate dealing with this problem several more times this week as I am deploying an app to a collection of users that also have the same Labview apps as the first user installed.

Answer 3

[Image Analyst]

There are known problems/errors/bugs/issues with tbb.DLL and the MATLAB R2013b compiler, at least for the Image Acquisition Toolbox. 'tbb.dll' is part of Intel's Threading Building Blocks library. You need to put tbb.dll in the same folder where your executable resides. There are a few other things that might be required also. Call them and tell them about the tbb.dll bug, and they can email you full directions for the workaround/fix.

[Yubo]

Thanks for the response. I will contact Intel to see if they have solutions.

[Image Analyst]

Intel will not have any idea what you're asking about. Like I said, the Mathworks has the workaround. Call the Mathworks instead of Intel.

[Yubo]

hmm okay I will contact mathworks then. Thanks.

[Image Analyst]

Can you please mark the Answer as "Accepted" then?

[Ralph]

Just wanted to add some supporting information: I had a similar tbb.dll issue (though the function was different). MathWorks support had no idea, blaming it on a host of random issues all of which turned out incorrect. I finally stumbled on this thread. The proposed solution (copying the tbb.dll to the executable's location) worked. In our case it appears that the machine was preferring a different tbb.dll version from NI. As many of us using the image aquisition toolbox will have installed NI MAX and the IVI libraries, this may account for so many problems in this particular community. I had hoped updating the system path to prefer the MCR would have the same affect, but this has not been the case.

[Image Analyst]

I've checked it with R2014a, and the issue remains. Not sure why it just started occurring out of the blue and I'd like an automatic fix. For now, I include tbb.dll in my installation package. Never had to do that before R2013b.

[Hannetjie]

Just wanted to add my thanks for this answer - I've also encountered this while attempting to compile a standalone program in 2014a. So this is a NI vs Matlab issue? On my machine I have several tbb.dll files - one in C:\Windows\System32, one in the Matlab bin folder, and one in the NI installation. Which one should be used? (My program makes use of Image Acquisition toolbox).