Visual C++ Runtime Library: “The Application has requested the Runtime to terminate in an unusual way. “

Symptoms of problem:

Running the library leads to this error:

UnusualRuntime

 

Root cause of problem:

This error is typically the result of a conflict between the Microsoft Visual C++ Redistributables libraries supplied with MATLAB, and those that are supplied by some third party applications.

 

Solution to problem:

To revert to a previous version of the C++ Redistributable libraries, you should uninstall all versions of your current 2005 and 2008 C++ Redistributable libraries through your Windows Control Panel, and reboot you machine. You can then re-install them by running the MATLAB-provided installers which can be found in the following locations:

For 32-bit Imatest:

 C:\Program Files (x86)\MATLAB\MATLAB Compiler Runtime\v81\bin\win32\vc90\vcredist_x86.exe

For 64-bit Imatest:

C:\Program Files\MATLAB\MATLAB Compiler Runtime\v81\bin\win64\vc90\vcredist_x64.exe

Note: for older releaseses, a different matlab folder will be used, for example, v714 for releases 3.10 and below.

See Also:

Read More

Best Practices for Calling Imatest IT Libraries

Only run in a single thread

The MATLAB runtime library does not support multiple threads using the same library.

For high speed parallel testing Imatest IT Parallel can use multiple processes to increase testing throughput up to three times. As of 5.1 ITP is now rolled in to IT.

 

Only initialize a single time for multiple runs

Initializing the library has significant computational cost. and the first call made to the library will run slower than subsequent runs.

The library should remain initialized throughout the life cycle of the calling program that should have reasonable longevity of its own.

 

mclTerminateApplication() or terminate() must be called once only per process

Calling mclTerminateApplication (C/C++) or terminate (Python) more than once may cause your application to exhibit unpredictable or undesirable behavior.

 

Do not use busy waiting while analysis runs

A main tester program that invokes a separate tester program should not use busy waiting or spinlocks to wait for the analysis to be completed.

 

Pass images directly instead of writing to disk

Use the direct passing of images in order to avoid having to write files to disk, only for them to be immediately read back by Imatest IT.

The availability of high speed SSD and HDD caches may reduce the expense of repeatedly writing and reading from disk, but have other risks associated with them and  

 

Use analysis modules that combine tests

SFRplus and eSFR ISO perform many different calculations on a single image.  These modules will always perform better

 

For SFR tests, use multiple regions on a single image

Multiple region selections allow a single module to test multiple points on the image. If you are cannot use the combined anaysis modules mentioned above, and are forced to use SFR for sharpness tests, make sure to use the multiple region selection.

 

Set the MCR_CACHE_ROOT and MCR_CACHE_SIZE environment variables

To substantially reduce startup times of IT/DLL and IT/EXE call, create and set the  MCR_CACHE_ROOT environment variable to a folder for which the user has read/write access, and the MCR_CACHE_SIZE environment variable to a value of 900000000 or higher. When these environment variables are set, the lengthy decompression stage that happens during IT initialization results in the data being stored in the MCR_CACHE_ROOT folder, instead of a temporary directory that is deleted after IT exits. If the relevant decompressed data is already present in MCR_CACHE_ROOT, then the decompression stage is skipped and substantial time is saved (~10s).

Example:

For Windows Vista and above:

To permanently set this environment variable you can use the  setx command. Open a command window and enter the following (substitute the folder path with your desired path)

setx /m MCR_CACHE_ROOT "C:\Users\<this_user>\My Documents\MCR_Cache"
setx /m MCR_CACHE_SIZE "900000000"

Note the ‘/m’ indicates that the variable will be defined for all users and that the new environment variable is only available after the command window is closed.

For Windows XP, please follow Microsoft’s instructions for setting environment variables.

For Linux:

To make MCR_CACHE_ROOT and MCR_CACH_SIZE available for all users, append its definition to either /etc/environment or /etc/profile.

MCR_CACHE_ROOT="/home/<this_user>/Documents/MCR_Cache"
MCR_CACHE_SIZE=900000000

Otherwise, modify the ~/.profile or ~/.bashrc files to append the definition.

 export MCR_CACHE_ROOT=/home/<this_user>/Documents/MCR_Cache
 export MCR_CACHE_SIZE=900000000

 

Throw hardware at the problem

When software configuration changes cannot give adequate speed improvements, utilizing computing hardware with faster clock speeds and more processor cores is the brute force way of increasing performance.

 

See Also:

Read More

Debugging Imatest IT

Debugging a console-based application

Much of the diagnostic information produced by the Imatest library is output to STDOUT and STDERR streams.  In 4.0 and beyond, this occurs in a  by adding the following INI setting:

[api]
debug=1

If you want to capture this output by your tester program and to save it to a log file, run your program like this:

testerprogram.exe > outputlog.txt 2>&1
 
Inspect the outputlog.txt should reveal details about what went wrong.  If you have any questions, send this file to support@imatest.com we should be able to determine the cause of the failure.  Also bundle your Imatest INI file, any JSON outputs that were produced, and if the failure is caused by a specific image please send us that image. 

Debugging a GUI-based application

In your calls to Imatest IT should be placed inside a try block ,with the catch block receiving a mwException object. can you then add a call to the print_stack_trace() member function of the mwException class. This will print the Matlab stack trace to cerr.  Note that there is only a print_stack_trace() for non-const mwException objects.   Example:
 
try {
     acquire_image(2, im_orig, vstr, source_id, vararginParam);
}
catch (mwException& e) {
     cout << “Run Error!” << endl;
     cerr << e.what() << endl;
     e.print_stack_trace();
}
 
GUI programs block the STDOUT and STDERR streams for the libraries you are calling. If cerr is not being output by your application, then the stream output must be captured. As part of our Operator Console Project, we have set up means of capturing these streams.  
 
See the following files for how to capture the streams:
 
 
Read More