The title of this is slightly misleading but its also specific to what I'm asking. I've got a project which uses Ogre and CEGUI. I'm only trying to get CEGUI up and running. I don't know that much about compilers and IDE's but I can program and I also read this:http://www.daniweb.com/software-development/cpp/tutorials/466177/understanding-c-from-source-to-binaries

My issue is the compiler cannot find the .dlls that I pointed it to. My specific error is

The program can't start because CEGUIOgreRenderer-0.dll is missing from your computer. Try reinstalling the program to fix this problem.

but I put the path to the .lib and .dll files in my MSVSE C++ 2010 additional library directories where I have verified that the files exist. Yet it is still unable to find this .dll at run time! What am I doing wrong?

Please don't direct me to the ogre and cegui websites, as I've already been there and they were not as helpful as I'd like them to be.

Dani AI

Generated

A few focused diagnostics that go beyond the usual "DLL not in PATH" advice (as noted) are likely to reveal the real cause given 's note about multiple copies and repeated attempts.

First, confirm whether the missing DLL is actually being rejected because one of its dependencies is absent or mismatched. Use a dependency-inspection tool (Dependency Walker or the modern "Dependencies") to load the CEGUI renderer DLL and look for any red/failed items — common culprits are the Visual C++ runtime, other third‑party libs, or a different Ogre/Boost build. A quick way from a VS command prompt:

dumpbin /dependents CEGUIOgreRenderer-0.dll
dumpbin /headers CEGUIOgreRenderer-0.dll   (check the MACHINE/architecture)

Second, verify architecture and CRT consistency. A 32-bit app will not load 64-bit DLLs and vice‑versa; mixing Debug/Release builds can also require different runtimes (and debug CRTs are not redistributable). Make sure the app, the CEGUI/Ogre DLLs, and the installed VC++ redistributable all target the same platform and runtime (for VS2010, the matching VC++ 2010 redistributable).

Third, observe what the OS actually tries to open. Run Process Monitor (Procmon) with a filter for the application name and look for "NAME NOT FOUND" or "PATH NOT FOUND" entries when the process starts. That shows exactly which paths the loader searched and which file name was requested (sometimes filename suffixes differ between debug/release builds).

Finally, clean up duplicate copies and simplify deployment: place the exact DLL (matching name, bitness and CRT) into the program's real output folder or use a post-build copy so the debugger runs the same binaries the app links against. If loader or side‑by‑side errors still appear, check the Windows Event Log for SxS errors — they often record missing CRT manifests. These steps usually expose the mismatch that produces a “missing” error even when a file is present.

Recommended Answers

All 4 Replies

The error is not related to the compiler. When you try to execute the program the operating system is looking for that DLL and can't find it. The DLL must be in one of the folders that is in the PATH environment variable or in the same folder as the *.exe that you are attempting to run.

I have tried both putting the required dlls into the exe's folder and putting the path to the .dlls into the PATH environment variable. I am still getting this error. I don't know what I'm doing wrong. I'm obviously doing something very wrong because nowhere else on the web has anyone else had this error. I've done countless searches.

Did you follow the steps to compile CEGUI library as explained here? It looks like all you get is the source code and you have to compile it yourself to generate the DLL.

Yes I did. I have the dlls on my hard drive but I don't know why they aren't being found. I have a few copies of it but even when I set all of my includes and lib directories to the same directroy containing the dlls it gives me this error. I'm not sure why I have so many copies though... It was a very painstaking and frustrating process to build cegui. I started over many times though I doubt any of those dlls or folders contain old dlls.

[edit] I think I copied the dlls from the build folder into my main folder and that is why there are many copies of them.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.