You are here: Start » Technical Issues » Troubleshooting


This article describes the most common problems that might appear when building and executing programs that use Aurora Vision Library.

Problems with Building

error LNK2019: unresolved external symbol _LoadImageA referenced in function
error C2039: 'LoadImageA' : is not a member of 'avl'

The problem is related to including the "windows.h" file. It defines a macro called LoadImage, which has the same name as one of the functions of Aurora Vision Library. Solution:

  • Don't include both "windows.h" and "AVL.h" in a single compilation unit (cpp file).
  • Use #undef LoadImage after including "windows.h".

error LNK1123: failure during conversion to COFF: file invalid or corrupt

If you encounter this problem, just disable the incremental linking (properties of the project | Configuration Properties | Linker | General | Enable Incremental Linking, set to No (/INCREMENTAL:NO)). This is a known issue of VS2010 and more information can be found on the Internet. Installing VS2010 Service Pack 1 is an alternative solution.

Exceptions Thrown in Run Time

Exception from the avl namespace is thrown

Aurora Vision Library uses exceptions to report errors in the run-time. All the exceptions are defined in avl namespace and derive from avl::Error. To solve the problem, add a try/catch statement and catch all avl::Error exceptions (or only selected derived type). Every avl::Error object has the Message() method which should provide you more detailed information about the problem. Remember that a good programming practice is catching C++ exceptions by a const reference.

        // your code here
    catch (const atl::Error& er)
        cout << er.Message();

High CPU Usage When Running AVL Based Image Processing

When working with some AVL image processing functions it is possible that the reported CPU usage can reach 50~100% across all CPU cores even in situations when the actual workload does not justify that hight CPU utilization. This behavior is a side effect of a parallel processing back-end worker threads actively waiting for the next task. Although the CPU utilization is reported to be high those worker threads will not prevent other task to be executed when needed, so this behavior should not be a problem in most situations.

For situations when it is not desired this behavior can be changed (e.g. when profiling the application, performance testing or in any situation, when high CPU usage interfere with other system). To block the worker threads from idling for extended period of time the environment variable OMP_WAIT_POLICY must be set to the value PASSIVE, before the application is started:


This variable is checked when the DLLs are loaded, so setting it from the application code might not be effective.

Previous: Processing Images in Worker Thread Next: Memory Leak Detection in Microsoft Visual Studio