How to debug DLL load failed: Invalid access to memory location

Question

I have a MinGW64-compiled DLL (python module), which gives error when loaded:

ImportError: DLL load failed: Invalid access to memory location

The DLL is linked only to 64bit libraries (Dependency Walker confirms that) and has debugging symbols. The code is fairly complex c++11 (around 30 source files), I cannot bisect it. I did successfully compile and tested other module with MinGW64 already, the toolchain works fine.

Some people around the web reported this error for code using SSE2 instructions (those are supported on my hw, and I don't use them explicitly) or reading from global vars which have not yet been initialized (there is a few functions with __attribute__((constructor)), but those should work in MinGW64 just fine, according to what I've read; update: I removed all constructor functions to make sure it was not the cause - it makes no difference).

What would be methods to analyze where is the error coming from?

What I tried:

When I load the DLL in debugger (using ctypes.WinDLL(...)), I unfortunately get only meaningless stacktrace from gdb - obviously, the error is trapped by ntdll.dll and signal is raised, but it does not give any further hints as to where the error came from:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000077c23522 in ntdll!ExpInterlockedPopEntrySListFault16 ()
   from C:\Windows\system32\ntdll.dll
(gdb) warning: HEAP[python.exe]:
warning: Invalid address specified to RtlSizeHeap( 00000000003B0000, 0000000002306830 )


(gdb) bt
#0  0x0000000077c23522 in ntdll!ExpInterlockedPopEntrySListFault16 ()
   from C:\Windows\system32\ntdll.dll
#1  0x0000000077c0c241 in ntdll!RtlZeroHeap ()
   from C:\Windows\system32\ntdll.dll
#2  0x0000000077c0c250 in ntdll!RtlZeroHeap ()
   from C:\Windows\system32\ntdll.dll
#3  0x0000000077c3c130 in ntdll!LdrLoadAlternateResourceModuleEx ()
   from C:\Windows\system32\ntdll.dll
#4  0x00000000003b0000 in ?? ()
#5  0x0000000002306830 in ?? ()
#6  0x00000000003b0000 in ?? ()
#7  0x00000000792e21c0 in ?? ()
#8  0x00000000003b0000 in ?? ()
#9  0x0000000077c3c0ba in ntdll!LdrLoadAlternateResourceModuleEx ()
   from C:\Windows\system32\ntdll.dll
#10 0xffffffffffffffff in ?? ()
#11 0x0000000050000061 in ?? ()
#12 0x0000000000000000 in ?? ()

I also linked the object files with a "hello world" executable, but gdb crashes already when opening the file with Reading symbols from woomain.exe (that's my executable):

Answer 1

The issue was that python linked to different msvcrt than MinGW when compiling the module -- it is reported at http://bugs.python.org/issue16472.