Cannot execute program if using boost (C++) libraries in debug-version on WinXP

Question

I'm using boost for several C++ projects. I recently made a upgrade (1.33.1 to 1.36, soon to 1.37), since then I cannot run any debug-builds anymore.

To be sure that no other project issues remain, I've created a minimum test-project, which only includes boost.thread, and uses it to start one method. The release build can be started, the debug build cannot, although the Dependency Walker shows that all required libraries are found (this also means that the required MS Debug CRT is found in the SxS directory).

On startup I only get:

Die Anwendung konnte nicht richtig initialisiert werden (0xc0150002). Klicken Sie auf "OK", um die Anwendung zu beenden.

Which means nothing more than "failed to initialize app". An internet research primarily lead to an MS Office installation problem, which recommends to perform a repair of WinXP.

So, beside the repair setup (which I think will not help as I'm talking about debug-dll issues), any ideas?

Ah, before I forget: Absolutely the same source-code leads to no errors on the build-machine (i.e., DLLs can be registered, means executed). So it's obviously an installation problem, but as the DLLs are there, and dependency-walker finds it, what else have I forgotten?

(edit) Well, I have not yet resolved my problem, but thanks to deemok I'm a step further. For the sake of reducing misunderstandings I give some clarifications below:

• The program fails to run on the developer-machine
• I am working with an installed VS2005 (it's a VC++8 project)
• I used the boost-setup from BoostPro, compiled all possible build-versions, and I double-checked that they are there (otherwise I'd already get linker-errors during build).
• and I double-checked any corner of include/lib/bin configuration I can think of -- as boost uses auto-linking on windows, with a special naming convention, the build or start-up would have failed, with a much more comprehensible error-message.
• I cannot use static linking, as boost.thread requires dynamic linking for DLL projects (I maybe could mess around here, but as this problem seems to happen only on my machine, I do not want to mess with this, as I'm sure the boost-guys had a reason to place that check in there in the first place)
• As I wrote, I checked with Dependency Walker, and it says everything is just fine.

Currently it seems to be an error in the boost-dll (maybe incorrect Manifest), will check that.

Answer 1

It's a Side-by-Side (SxS) issue – simply copying the DLLs is not enough anymore.

Regarding your specific problem concerning the Debug build, see: http://stackoverflow.com/questions/264385/running-vc2008-debug-builds-on-non-dev-machines

Short answer:

You can't, because there's no installer redist for the debug runtime (and in fact the software license forbids distributing it, so you'd be breaking the EULA even if you did get something put together).

So, you'll need to install Visual Studio there.

However, if you still want to try without taking that path, you could read puetzk's answer in its entirety.

Or, you could try to link everything statically.

Answer 2

Get yourself the dependency walker. Open your application exe in it. It will show you all the dlls that your application needs but can't load/access.

If that's not enough, you can also profile your app with the dependency walker, which will give you a lot of output to find out where the problem is.

[edit] since you only have problems with the debug build: make sure that when you upgraded boost, you also rebuilt not just the release binaries but also the debug binaries of boost. And of course, make sure that the debug build was built with the same version of VisualStudio than you're using now.

And make sure that the include paths (tools->options->projects and solutions->VC++ directories) are correct: the paths to the latest boost version must be there, not maybe to an older version.

Answer 3

So you are using the pre-built libraries from BoostPro? If so, your environment might somehow be slightly different to the one they were built in (TR1 feature pack or not, etc). Perhaps best to try building Boost yourself in your specific environment.