The application was unable to start correctly (or failed to initialize properly)

When one of the following error messages is shown after executing an application:

  • The application was unable to start correctly (0xc<7 hexadecinal digits>). Click OK to terminate the application.
  • The application failed to initialize properly (0xc<7 hexadecinal digits>). Click OK to terminate the application.

there is no information about what is the real problem. It may get more mystic if you are developing the application. You will try to debug it without success, since the same error will appear in Visual Studio, or any other IDE, and the first line of code in your main function is not reached. The application really can’t start.

This error usually means that a shared library (dll) is missing. If the missing shared library is a direct (first level) dependency, the error is different and informative (The program can’t start because XXXXXX.dll is missing from your computer). However, if a shared library calls another shared library, the former and obscure error will be displayed instead.

The solution: download the Dependency Walker application, and run it with your application executable to find the missing shared library file name. Once you know the file name, google it, find and download the prerequisite that contains the library, and install it.

Take into account that:

  1. The shared library version matters. If you install a different prerequisite version than the one originally used for compiling the calling shared library, the error may be still thrown. Therefore, you may try more than one version until you find the right one.
  2. Do not download single dll files from untrusted sites, since there is no guarantee that those files are untouched.

Real case scenario: your application uses some third-party shared libraries as black boxes (you don’t have the source code). Someone updates one of these third-party libraries at the common repository, and the updated library has a new dependency. When you update your local copy, compile and execute, you will find the error.

P.S.: In Spanish, the errors are translated as “La aplicación no se ha podido inicializar correctamente (0xc<7 dígitos hexadecimales>)” and “El programa no puede iniciarse porque falta XXXXXX.dll en el equipo”.


Custom compiling of Cryptopp for my project

I want to develop a very simple licensing system. I decided to use Crypto++ v5.6.2 for generating public and private keys, cypher and decipher files. This library is build under Windows with Visual Studio and its solution files, but my project is using CMake for generating these solution files. Therefore, either I can write some CMake files for compiling Crypto++ or I can compile it and move the resulting files to my environment, using CMake to collect and include them in my solution. The latter is the approach that I have chosen with some libraries, since it is usually really difficult to write CMake files for building a library that you have not develop.

These are the steps I followed:

  1. Read Readme.txt at the root folder inside the zip file, and pay attention to the MSVC section. The cryplib project is the full static library project.
  2. I am using Ogre and other projects that force me to use shared C++ run-time libraries. Criptop++ use static C++ run-time libraries by default. As I explained in other posts, make sure that this setting is consistent across all your dependencies. Therefore, go to the cryplib Project Properties -> C/C++ -> Code Generation and switch from Multi-threaded to Multi-threaded DLL, in debug /MTd to /MDd and in release /MT to /MD.
  3. Ogre also uses multi-byte character set, so switch for all configurations General -> Character Set to Use Multi-Byte Character Set.
  4. Make sure Code Generation -> Enable Enhanced Instruction Set is set to /arch:SSE2 in release and debug.
  5. Following the same philosophy than Ogre and other libraries, I will build release and debug libraries with different names, in order to make it easier to add them by hand in my CMake project files. Switch to the debug configuration and find Target Name property at General, change its value to $(ProjectName)_d. It is advisable to rename the *.pdb files with the same name than the target name, so go to C/C++ -> Output files and and change its value to $(OutDir)$(TargetName).pdb.
  6. I will create another configuration for compiling in release mode with debugging information. Click on the Configuration Manager button. Unfold the Active Solution Configuration list, and select <New>. Then, choose in Copy settings from the release configuration, and use the CMake name for this kind of build RelWithDebInfo. Once the new configuration has been created, I recommend to save, close the IDE, and open it again. Now, make sure the release configuration does not include debugging information. C/C++ -> Debug Information Format should be empty, and this property in RelWithDebInfo configuration should be set to Program Database /Zi. Lastly, disable any optimization by setting C/C++ -> Optimization -> Optimization to Disabled (/Od).
  7. I do not want the whole program optimization, because other libraries do not use it, and some warnings or errors may happen when the final linking of my application is done. Hence, go to General -> Whole Program Optimization and set No Whole Program Optimization in release and RelWithDebInfo configurations. Besides, in Librarian -> Link Time Code Generation set it to No. Deactivation of /LTGC optimization flag must be done in both places, when compiling and when linking.

Finally, you are ready to compile and include the final results in your project. I created a new folder called Cryptopp with two folders: lib for the binaries and include for the header files. In my CMake files, ExternalDependencies.cmake contains the path to the include and binary folders, and the name of the libraries for the debug and release configurations, such as:






Stencil shadows in Ogre and Blender model exportation

If you are gonna use stencil shadows in Ogre, you should carefully read the manual page about this shadowing technique, and be sure to fully understand what is explained there. Besides, you can find some useful hints and tips regarding this topic that I have discovered while adding shadows to my scenes.

  1. Any object (mesh) casting shadows must contain an edge list, which can be generated either when exporting the mesh in Blender (or any other modelling tool) or calling Mesh::buildEdgeList before the mesh is used in run-time. If you are using Blender, make sure that the option Edge Lists is enabled when exporting your model (like I explained in a previous post).

    Edge Lists option when exporting.

    Edge Lists option when exporting.

  2. Current Ogre release (v1.8.1) has a bug when computing stencil shadows if a light source is placed inside an object. Read this thread. Solutions: a) do not place a light source inside an object (with edge list), b) apply the patch posted in the previous thread to your Ogre sources (this patch will be included in the next maintenance release), c) consider switching to the texture shadows technique.
  3. Stencil shadows project the object geometry. The shadow caster class (OgreShadowCaster) has a 16-bit index limit on the number of vertexes. This limit will only be shown to the user in debug mode with an assert. In release mode, this limit will not trigger anything, but shadows will not work properly. In addition, the performance may be seriously penalized, if big meshes are used with this technique due to the geometry projection. Therefore, if shadows do not work properly, make sure none of your meshes exceeds the 16-bit limit executing in debug mode. If this requirement is not meet, you can split the mesh in different pieces (that will help Ogre to cull non visible parts), or reduce the number of vertexes.

CMake and the executable stack size in Visual Studio

Today I have been struggling with my first mystical error at my new job. The C++ project was able to compile and execute. At least, the screen was showing the 3D initial menu. However, when I tried to open any of the sub-applications where big 3D models where used, strange exceptions were thrown, such as out of memory when loading a texture, vertex buffer can not be allocated, and similar ones depending on the sub-application executed.

I have been porting the project from a manually maintained .sln file to CMake. So, the first step was to make sure that the original executable was working, and it was. Then, I compared the compilation and linking flags in the both project files, and I removed the new flags, which were not present in the original solution, one by one. Finally, I discovered (after 5 hours) that CMake (version 2.8.10) adds to the linker flags /STACK:10000000, which means that the heap size is initialized to 10MB, instead of the default 1MB. Adding the following lines to the main CMake file:
CACHE STRING “Flags used by the linker.”

solved the problem. Note that a similar problem may occur if there are multiple threads in the application, since the total amount of memory used will be num_threads by stack_size.

Note that this flag must be also removed from all your project dependencies that use CMake for generating project files. Then, the modified dependencies must be rebuild and finally your project, too.

Compiling Bullet v2.81 rev2613 under Windows 7 with Visual Studio

My project uses the Bullet physics engine together with the Ogre graphics engine, so the compilation of Bullet must be done with certain settings to properly build the final executable. These settings are, fast floting point and, the most important, DLL runtime of C/C++ (that is, /MD in release and /MDd in debug).

  1. You can download the latest version of Bullet and in the download section of the project’s code webpage.
  2. Open the CMake GUI and select the folder where you decompressed the source files using the “Browse Source” button. Select a folder where the library will be built with the “Browse Build” button.
  3. You can modify the options at your will, but I used the following:
    • USE_DX11
    • USE_GLUT
    • USE_MSVC_FAST_FLOATINGPOINT (as Ogre graphic engine does)
    • USE_MSVC_RUNTIME_LIBRARY_DLL (as Ogre graphic engine does)
    • In my CMake project, some libraries have a different name only in the debug configuration. Therefore, make sure that CMAKE_RELWITHDEBINFO_POSTFIX is empty.
    • Remove the MinSizeRel configuration if you are not using it.
  4. Configure and generate the project.
  5. Build it in MSVC and run some of the tests.
  6. You are now ready to include this library in your project together with Ogre.

Compiling CEGUI under Windows 7 with Ogre support in Visual Studio

You can download the latest version of CEGUI, I used 0.7.7, and its dependencies in the download section of the webpage.

The compilation instructions can be found in the Main docs, section Supported systems and compilation. However, this documentation is not enough detailed to build this library with Ogre support.

Here are some additional steps and tips:

  1. Make sure that you have installed Ogre as an SDK. Unfortunately, CEGUI does not use CMake for generating the project files. As a consequence, an Ogre build with CMake must be installed in order to properly import headers and libraries in CEGUI.
  2. As explained in the documentation, unzip the sources. Then, the dependencies inside the sources folder.
  3. Go to projects/premake and edit the file config.lua. Make the following changes:
      WANT_STATIC_BUILD = false
      I need the release with debug symbols configuration, besides release and debug, and I want to generate only dlls.
      If you need the static versions of the libraries for using them with Ogre, make sure this is set to true, because Ogre links by default against the dynamic version of the C++ libraries. If you try to link an executable to a library that has C++ dynamic dependencies (/MD) and, at the same time, to another library that has C++ static dependencies (/MT), you will end up with a linking error 2005 in Visual Studio or potential errors passing CRT objects across DLL boundaries. Never mix C/C++ runtime libraries. Everything must be compiled with /MT or /MD (/MTd or /MDd for debugging).
    3. OGRE_PATHS = { “D:/Program Files (x86)/OGRE”, “include/OGRE”, “lib/$(Configuration)” }
      OIS_PATHS = { “D:/Program Files (x86)/OGRE”, “include/OIS”, “lib/$(Configuration)” }
      Make sure that this paths point to the Ogre SDK folder. The $(Configuration) in the linking path will be replaced in Visual Studio by the current configuration when building. Note: the release with debug info build will not work, because Ogre uses the typical RelWithDebInfo CMake name and CEGUI uses a different name, ReleaseWithSymbols. Open the solution file, choose the ReleaseWithSymbols configuration, right click on the CEGUIOgreRenderer project, go to properties, Configuration Properties, Linker, General, Additional Library Directories. Replace D:/Program Files (x86)/OGRE/lib/$(Configuration) by D:/Program Files (x86)/OGRE/lib/RelWithDebInfo.
      { “D:/Program Files (x86)/boost/boost_1_51”, “”, “lib”, “CEGUIOgreRenderer” },
      { “D:/Program Files (x86)/boost/boost_1_51”, “”, “lib”, “CEGUISampleHelper” },
      { “D:/Program Files (x86)/Microsoft DirectX SDK”, “Include”, “Lib/x86”, “CEGUIDirect3D9Renderer” }
      Add the boost path for building the OgreRenderer and the SampleHelper. Besides, add the path to the DirectX SDK for the Direct3D9Renderer.


That’s all. Run the *.bat in the config.lua folder for your Visual Studio version. If your MSVC++ version is missing, use the nearest version. MSVC++ will take care of upgrading the project files.

Installing OpenNI 1.5 under Windows

The OpenNI 1.5 library for developing software with Kinect can be installed under Windows 7 x86-64 SP1 following this instructions:

  1. Download and install the drivers. Choose the proper version, x86 or x86-64, according to your OS version.
  2. Install OpenNI: openni-win32-
  3. Install NITE: nite-win32-
  4. Install SensorKinect: SensorKinect091-Bin-Win32-v5.1.0.25.msi

Note that the software for steps 1 and 4 comes from a GitHub repository, and the software for steps 2 and 3 should come from the official OpenNI website. Besides, note that the driver must match your system type (x86 or x86-64), but the OpenNI software should match your development environment type, which may be different, like in my case (x86 aka win32).

Never install the official OpenNI SensorKinect package (about 900KB), because Kinect will not work. Use the mentioned GitHub package (about 4MB).

Check your installation with any of the OpenNI demos.

Important: the official page has released OpenNI v2.0 (in beta stage), which completely breaks the compatibility with OpenNI 1.5.