MinGW + MSYS + Eclipse CDT shared libs: The application failed to initialize properly (0xc0000005).
Lars Uffmann
I am currently working on updating the Eclipse guide for wxWidgets in
the wiki to the latest software versions.
I have documented my MSYS and MinGW installation process in this guide:
http://wiki.wxwidgets.org/HowTo:_Install_MSYS_and_MinGW_for_use_with_Eclipse_CDT
Eclipse was set up according to
http://wiki.wxwidgets.org/Eclipse,_CDT_%26_MingW_%26_MSYS_Setup_Guide
Now I have stumbled into some odd behaviour:
When I build the wxWidgets sampleMinimal, with shared library settings
(wxconfig with the option "--static=no"), my final executable will abort
with the critical error message "The application failed to initialize
properly (0xc0000005)." This does *not* happen with a static=yes build,
nor does it happen when I build the configTest example (hello-world-style).
I was wondering if maybe something is wrong with my wxWidgets
enable-shared build/configuration. Would it help if I post my configure log?
Or does anyone have an idea on how to narrow down the causes for this
error message?
I am not using any post build step (such as strip.exe) on the executable
to experience this behaviour.
Grateful for any help!
Lars
Rüdiger Ranft
> Hey everyone!
> Now I have stumbled into some odd behaviour:
>
> When I build the wxWidgets sampleMinimal, with shared library settings
> (wxconfig with the option "--static=no"), my final executable will abort
> with the critical error message "The application failed to initialize
> properly (0xc0000005)." This does *not* happen with a static=yes build,
> nor does it happen when I build the configTest example (hello-world-style).
>
> I was wondering if maybe something is wrong with my wxWidgets
> enable-shared build/configuration. Would it help if I post my configure
> log?
You can examine the dependencies of your program with the Microsoft
"dependency walker". Look for errors in the output, and which dll causes
them. 0xc0000005 is likely related to either a missing execute right in
the NTFS ACL of the dll, or a damaged dll manifest (either resource or
.dll.manifest file). You can try to execute the program in Windows 2000.
If the program works in W2K it is very likely a manifest problem, since
the manifest resources are introduced win XP.
HTH
Rudi
Lars Uffmann
> You can examine the dependencies of your program with the Microsoft
> "dependency walker". Look for errors in the output, and which dll causes
Will
http://www.dependencywalker.com/
do the trick? I didn't know Microsoft had it's own...
Dependency Walker output:
------------
Started "SAMPLEMINIMAL.EXE" (process 0xF74) at address 0x00400000.
Successfully hooked module.
Loaded "NTDLL.DLL" at address 0x7C900000. Successfully hooked module.
Loaded "KERNEL32.DLL" at address 0x7C800000. Successfully hooked module.
DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" called.
DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL"
returned 1 (0x1).
[..left out some other successful loads..]
Loaded "SHLWAPI.DLL" at address 0x77F60000. Successfully hooked module.
Second chance exception 0xC0000005 (Access Violation) occurred in
"NTDLL.DLL" at address 0x7C966668.
Exited "SAMPLEMINIMAL.EXE" (process 0xF74) with code -1073741819
(0xC0000005).
-------------
I'll google somewhat on that, however if anyone knows more about this,
please feel free to enlighten me...
> them. 0xc0000005 is likely related to either a missing execute right in
> the NTFS ACL of the dll, or a damaged dll manifest (either resource or
> .dll.manifest file). You can try to execute the program in Windows 2000.
> If the program works in W2K it is very likely a manifest problem, since
> the manifest resources are introduced win XP.
Virtual Machine 4tw... will try to get my hands on a copy of W2K.
Best Regards,
Lars
Lars Uffmann
> Loaded "NTDLL.DLL" at address 0x7C900000. Successfully hooked module.
> Second chance exception 0xC0000005 (Access Violation) occurred in
> "NTDLL.DLL" at address 0x7C966668.
Doing the math here gets me to the violation occuring at address
0x7c966668 - 0x7c900000 = 0x66668 inside NTDLL.DLL, being seemingly
within the memory area of the function
RtlRaiseStatus (entry point 0x66642)
and just 9 bytes before the start of function
RtlRandom (entry point 0x66671)
- more to google for me, as to how RtlRaiseStatus can cause an
exception like that, and I guess this isn't really wxWidgets related
anymore, then... Help appreciated nevertheless...
Best Regards,
Lars
Lars Uffmann
chance exceptions" so far - possibly the error cause is in the first
chance exception?
-------------------
Started "SAMPLEMINIMALDEBUG.EXE" (process 0x7D8) at address 0x00400000
by thread 1. Successfully hooked module.
Loaded "NTDLL.DLL" at address 0x7C900000 by thread 1. Successfully
hooked module.
[...]
First chance exception 0xC0000005 (Access Violation) occurred in
"NTDLL.DLL" at address 0x7C919136 by thread 1.
First chance exception 0xC0000005 (Access Violation) occurred in
"NTDLL.DLL" at address 0x7C966668 by thread 1.
Second chance exception 0xC0000005 (Access Violation) occurred in
"NTDLL.DLL" at address 0x7C966668 by thread 1.
Exited "SAMPLEMINIMALDEBUG.EXE" (process 0x7D8) with code -1073741819
(0xC0000005) by thread 1.
------------------
This leads to address 0x19136 within ntdll.dll, being within function
RtlGetUserInfoHeap (entry point 0x18fa9)
at position 0x18fa9+0x18d (397 dec.)
Just to add some more info....
Lars Uffmann
"During startup program exited with code 0xc0000005."
When I try to backtrace, gdb answers
"No stack."
I linked a debug configuration in Eclipse, using Linux GCC toolchain
(MSYS make). So from my understanding, there should be debug information
in the executable (being 800kByte instead of the Release's 100kByte).
Any more ideas?
Lars
Rüdiger Ranft
> Rüdiger Ranft wrote:
>> You can examine the dependencies of your program with the Microsoft
>> "dependency walker". Look for errors in the output, and which dll causes
>
> Will
> http://www.dependencywalker.com/
> do the trick? I didn't know Microsoft had it's own...
They are the same.
> Dependency Walker output:
> ------------
> Started "SAMPLEMINIMAL.EXE" (process 0xF74) at address 0x00400000.
> Successfully hooked module.
> Loaded "NTDLL.DLL" at address 0x7C900000. Successfully hooked module.
> Loaded "KERNEL32.DLL" at address 0x7C800000. Successfully hooked module.
> DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" called.
> DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL"
> returned 1 (0x1).
>
> [..left out some other successful loads..]
>
> Loaded "SHLWAPI.DLL" at address 0x77F60000. Successfully hooked module.
Welcome in dll hell. Is the build machine the same as the execution
machine? Can you execute an example program on the build machine?
I got a similar error once when i accidentally copied a windows runtime
lib to another windows version.
bye
Rudi
Lars Uffmann
>> Loaded "SHLWAPI.DLL" at address 0x77F60000. Successfully hooked module.
> Welcome in dll hell. Is the build machine the same as the execution
> machine? Can you execute an example program on the build machine?
Yes, I only started testing on a different machine *after* execution on
the build machine failed, and I have successfully compiled, linked and
executed a simple hello-world-type program on that machine.
The problem only occured when I tried the wxWidgets minimal sample, I
was wondering if this problem is reproducible by others with the most
recent mingw/msys versions (configuration described in my wiki guide).
I appreciate your help by the way :)
Lars (currently trying to build the development snapshot of
wxWidgets, trying to see if that makes a difference)
Rüdiger Ranft
> R�diger Ranft wrote:
>>> Loaded "SHLWAPI.DLL" at address 0x77F60000. Successfully hooked module.
>> Welcome in dll hell. Is the build machine the same as the execution
>> machine? Can you execute an example program on the build machine?
>
> Yes, I only started testing on a different machine *after* execution on
> the build machine failed, and I have successfully compiled, linked and
> executed a simple hello-world-type program on that machine.
You can copy the hello-world to the other machine (without the wx libs),
look for its dependencies with dependency-walker, copy one of its
missing dlls, recheck, copy... until you have found which one of the
libs is causing the problems.
bye
Rudi
Lars Uffmann
> You can copy the hello-world to the other machine (without the wx libs),
> look for its dependencies with dependency-walker, copy one of its
> missing dlls, recheck, copy... until you have found which one of the
> libs is causing the problems.
Actually, that is what I did the other day - I just didn't think this
would indicate which lib is causing the problem: I thought the
dependency check was performed by windows before any libraries were
actually loaded.
According to this, the problem is occuring as soon as
wxbase28_gcc_custom.dll
is made available in the path for the application.
Best Regards,
Lars
Lars Uffmann
> Hey everyone!
>
> I am currently working on updating the Eclipse guide for wxWidgets in
> the wiki to the latest software versions.
>
> I have documented my MSYS and MinGW installation process in this guide:
> http://wiki.wxwidgets.org/HowTo:_Install_MSYS_and_MinGW_for_use_with_Eclipse_CDT
>
>
> Eclipse was set up according to
> http://wiki.wxwidgets.org/Eclipse,_CDT_%26_MingW_%26_MSYS_Setup_Guide
>
> Now I have stumbled into some odd behaviour:
Problem reproduced on a WinXP SP3 Dell Latitude laptop (different computer).
I am pretty sure there is something wrong with one of the recent MinGW,
MSYS or wxWidgets files. OR - I have messed up my settings somewhere...
Maybe someone can take the time to reproduce the problem using my
guides, and help me pinpoint this issue?
Best Regards,
Lars
Lars Uffmann
> Lars (currently trying to build the development snapshot of wxWidgets,
> trying to see if that makes a difference)
Update: Same problem occures with development snapshot of 2.9.0 - now I
am trying different versions of MinGW / MSYS to track this issue down.
Best Regards,
Lars
Lars Uffmann
MinGW 5.1.6 installer to build wxWidgets 2.8.11 stable release,
wxWidgets sampleMinimal runs perfectly fine.
So in summary, I will move this thread into the MinGW mailing lists, and
would like to issue a WARNING to everyone considering to use any later
MinGW packages than distributed in the 5.1.6 packaged installer: At
least one of those packages has a severe bug that is a showstopper for
wxWidgets!
Best Regards,
Lars
Lars Uffmann
http://article.gmane.org/gmane.comp.gnu.mingw.user/33216/
Apparently, one of the recent binutils versions was not compatible with
gnu c++ programs anymore in the default configuration:
You needed to add '-Wl,--enable-runtime-pseudo-reloc-v2' to the g++
command line call to avoid the 0xc0000005 error.
In the most recent binutils version 2.20.51 (link to article 33216
above) this option has been enabled by default, and wxWidgets libraries
are built properly, the wxWidgets sampleMinimal executes just fine.
Best Regards,
Lars