The application was unable to start correctly (0xc0000000d).

[tokiwotomare]

So. My old development machine finally kicked the bucket. I'm on a new machine, a (somewhat) new environment, and trying to compile a program that worked just fine on the old machine on this new one.

The old machine was:
- Windows 7 basic (or whatever the very lowest version was)
- 32 bit
- Linking the static sfml2 libraries
- Using VS2010 express
- Worked like a champ!

The new machine is:
- Windows 7 ultimate
- 64 bit
- Linking the dynamic sfml2 libraries, which I re-compiled on this machine
- Still using VS2010 express
- Not working!

The program compiles just fine, but the second it starts, it crashes with the very helpful error message in the title.

Any ideas?

[David]

So. My old development machine finally kicked the bucket. I'm on a new machine, a (somewhat) new environment, and trying to compile a program that worked just fine on the old machine on this new one.

The old machine was:
- Windows 7 basic (or whatever the very lowest version was)
- 32 bit
- Linking the static sfml2 libraries
- Using VS2010 express
- Worked like a champ!

The new machine is:
- Windows 7 ultimate
- 64 bit
- Linking the dynamic sfml2 libraries, which I re-compiled on this machine
- Still using VS2010 express
- Not working!

The program compiles just fine, but the second it starts, it crashes with the very helpful error message in the title.

Any ideas?

Show me your code, although I do believe it's the 32-64 bit conversion that's screwing things up (since the error is in hex code)

Here's something I found: http://www.sevenforums.com/general-discussion/41098-application-unable-start-correctly.html

[tokiwotomare]

The code is ... quite large! Since I can't really narrow down the specific culprit, I can't really post it.

Someone in that thread suggested that his problem was a side-by-side with the .NET framework. Does SFML require a specific one? I didn't think it required .NET.

Edit: Another question -- are there pitfalls related to 64-bit that I should watch out for? I thought that if I just recompiled the current source on my 64-bit machine it should be fine.

[David]

Gah, I'd rather not go into details

I just googled your error message and came up with what looks like potential results  :wink:

[tokiwotomare]

^^

Thanks for the effort anyway!

[Laurent]

The code is ... quite large! Since I can't really narrow down the specific culprit, I can't really post it.

Really? If it's a configuration problem (and it most likely is) the code shouldn't matter. Do you mean that you get no error with simple codes (like the SFML examples)?

[tokiwotomare]

Good question -- I'll try a simple SFML example tonight and see if it runs.

What I meant was that I think it is indeed a configuration error, as the code doesn't even start to run (stepping into the debugger, for example, or setting a breakpoint on the entry of main).

[tokiwotomare]

Okay, so I tried the very simple Window example --

Code: [Select]

#include "stdafx.h"
#include <SFML/Window.hpp>

int main()
{
    // Create the main window
    sf::Window App(sf::VideoMode(800, 600, 32), "SFML Window");

    // Start main loop
    bool Running = true;
    while (Running)
    {
        App.Display();
    }

    return EXIT_SUCCESS;
}


Linking only sfml-window-d.lib (which I re-compiled on this machine), and using SFML_DYNAMIC.

Still gives me the same error!

[Groogy]

Could the application be compiling in 64bit while the sfml dll's are 32bit? Or the other way around? I believe that would screw things over pretty badly.

Try with forcing both your project and SFML to 32 bit and see if it works.

[tokiwotomare]

Just checked -- both are compiling in Win32 Debug mode.

[Groogy]

Linking only sfml-window-d.lib (which I re-compiled on this machine), and using SFML_DYNAMIC.

Still gives me the same error!

Might be this, sfml-window depens on sfml-system so you have to link that one too.

[tokiwotomare]

It wouldn't compile if that were the case -- I suffered through setting up linking and all that the first time

[tokiwotomare]

So, some additional info -- it appears to be the actual linking that's causing the crash.

I took the simple tutorial example and tried building it without linking the library (and commenting out subsequent library calls). It ran!

However, linking the library (in this case, sfml-window-d.lib) causes this crash. Any ideas?

[tokiwotomare]

A bit more additional info:
- I switched over to my Ubuntu box, and, using all the same settings (what to link, dynamic vs static, etc), the only difference being the actual libraries compiled (64-bit Linux instead of Windows) ... it works just fine.
- I switched over to Code::Blocks on the Windows box, thinking that maybe VS2010 was doing something weird. Recompiled the libraries; linked everything the same way ... I get the same error. So it's not an IDE quirk; it's definitely something going wrong with Windows 7.

My best guess -- based on a lot of very general, "not sure what I'm looking for" Googling -- is that there's some mix-up going on between 32- and 64-bit, but ... I have no idea what, or where to even begin with that.

As far as I could tell, there aren't 64-bit-specific Windows libraries in the source.

Any ideas at all? I'll try anything at this point! I'm happy to develop on the Ubuntu box, but the added inconvenience is a pain  :lol:

[Xander314]

Sorry to bump an old thread. However, I was having a similar problem and I fixed by swapping from using the x64 libsndfile-1.dll to the x86 libsndfile-1.dll.

I am also on Windows 7 64bit. However, unless you have specifically configured VC++ Express to work with the 64bit toolset of the Windows SDK, you are bound to 32bit compilation anyway.

I assume I could use the 64bit one if I compiled a 64bit application?