User forums > Help

codeblocks fails to launch after svn update

(1/3) > >>

mkborregaard:
++Moved from the 'using codeblocks' forum (http://forums.codeblocks.org/index.php/topic,12104.msg82206.html#msg82206)++

I just updated my code::blocks sources from the SVN repository after about half a year of using the same C::B version. My resulting code_blocks.exe file now fails to launch with "The application failed to initialize properly (0xc00000005)". I updated and recompiled my wxMSW to 2.8.10, rebuilt, problem persists. I waited a few days, did a new SVN update, rebuilt, problem persists.
I did a search in here and found one post: http://forums.codeblocks.org/index.php/topic,8675.msg63238.html. I identified mulitiple copies of mingwm10.dll and strip.exe in my path, and exchanged all versions with the one in my MinGW folder, but the problem persists.
Does any one have a suggestion?
My old codeblocks (compiled from SVN sources 7 May 2009) still works fine, so it must be something about the new version or how I compiled it.
I use MinGW-5.1.3 as compiler on windows XP.

oBFusCATed:
Try the dependency walker (http://dependencywalker.com/) and see if there aren't missing dlls

stahta01:
Try building a small wxWidgets project that links to the same wxWidgets used in your Code::Blocks.

Note, make sure to use DLL version of wxWidgets.

If that works, then it rules out your wxWidgets build as a likely cause.

If it fails, it points to an compiler or wxWidgets cause as most likely.
I would build the wxWidgets minimum using just makefile to eliminate C::B.

Tim S.

stahta01:
I would still put my money on an Compiler Configuration/Installation type problem.

The things I do to keep my Compilers working right.

The ONLY Compilers I keep to the Windows System Path is MS Visual Studio.
All others, I remove them from the PATH Environmental Variable.
NOTE, I also remove Cygwin from PATH Environmental Variable.

I then test the above using which/where cmd commands.
http://gnuwin32.sourceforge.net/packages/which.htm


--- Code: ---which mingwm10.dll
which gcc.exe
which g++.exe
which codeblocks.dll
which wxmsw28u_gcc_cb.dll

--- End code ---

The above should then find no (one at most) copies of the dll/exe (except in current folder).
Note, getting only one result for each of the above would be OK along as they are only the ones used by your Code::Blocks installation.

Tim S.

mkborregaard:
Thanks for the replies!
I tried out your suggestions, but have not gotten it to work yet.
I first built the sample c::b wxwidgets project with the new wxwidgets (2.8.10), using my old codeblocks.exe. Worked like a charm.
I tried running 'which', found 0 or 1 versions of the dlls you suggested:

--- Code: ---which mingwm10.dll
> c:\c++\mingw\bin\mingwm10.dll
which gcc.exe
> c:\c++\mingw\bin\gcc.exe
which g++.exe
> c:\c++\mingw\bin\g++.exe
which codeblocks.dll
(not found)
which wxmsw28u_gcc_cb.dll
(not found)

--- End code ---
I have a codeblocks.dll in both the old and new codeblocks folder, but not in the path.
My wxwidgets dll is called wxmsw28u_gcc_custom.dll, not wxmsw28_gcc_cb.dll.
Though I do have MSYS and Cygwin, they are not in my PATH or Path.

I tried running dependency walker, and that complains it cannot find 'ieshims.dll" and "wer.dll", and that "mpr.dll" has a problem. However, I get that same message when i run dependency walker on my working cb. Anyway, these are delay-loaded, so I guess they should not cause startup crash?

Any ideas for how to proceed?

Navigation

[0] Message Index

[#] Next page