Reldebug built Kolab-E5RC-2011-04-01-22-35.exe
With an attached gdb --nofork I get the following backtrace:

warning: Debug:kontact(4504)/kio (KDirWatch) KDirWatchPrivate::useQFSWatch: fsWatcher->addPath "c:/program files/kolab e
5rc/share/emoticons/kde4/emoticons.xml"

[New Thread 4504.0x143c]
[New Thread 4504.0x1410]
[New Thread 4504.0x1418]
[New Thread 4504.0x1378]
[New Thread 4504.0x149c]
warning: Critical error detected c0000374


Program received signal SIGTRAP, Trace/breakpoint trap.
0x770135b6 in ntdll!RtlpSetUserPreferredUILanguages () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0  0x770135b6 in ntdll!RtlpSetUserPreferredUILanguages () from C:\Windows\system32\ntdll.dll
#1  0x77014513 in ntdll!RtlpSetUserPreferredUILanguages () from C:\Windows\system32\ntdll.dll
#2  0x770145f3 in ntdll!RtlpSetUserPreferredUILanguages () from C:\Windows\system32\ntdll.dll
#3  0x76fcb2c7 in ntdll!RtlTraceDatabaseValidate () from C:\Windows\system32\ntdll.dll
#4  0x765398cd in msvcrt!free () from C:\Windows\system32\msvcrt.dll
#5  0x003f0000 in ?? ()
#6  0x1a291592 in _M_dispose (proto=GpgME::OpenPGP, reason=0x22c6b8)
    at c:/kdepim-e5-builds/kdepim-e5-package_2011-04-01-19-52/mingw/bin/../lib/gcc/i686-w64-mingw32/4.4.5/../../../../in
clude/c++/4.4.5/bits/basic_string.h:236
#7  ~basic_string (proto=GpgME::OpenPGP, reason=0x22c6b8)
    at c:/kdepim-e5-builds/kdepim-e5-package_2011-04-01-19-52/mingw/bin/../lib/gcc/i686-w64-mingw32/4.4.5/../../../../in
clude/c++/4.4.5/bits/basic_string.h:503
#8  ~Error (proto=GpgME::OpenPGP, reason=0x22c6b8) at u:/include/gpgme++/error.h:41
#9  check (proto=GpgME::OpenPGP, reason=0x22c6b8)
    at w:\svn-src\kdepim-e5\libkleo\backends\qgpgme\qgpgmebackend.cpp:347
#10 0x0022c57f in ?? ()
#11 0x00000000 in ?? ()
(gdb)

Bug is still valid, in the current E5 packages crypto has been disabled so this no longer occurs.

Created attachment 59172 [details]
Invalid Address to RtlValidateHeap

I did some more debugging on this. What is visible as a crash is a critical error c0000374 (Heap Overrun) caused by the Windows Heap Manager. This exception is thrown because the Heap Header of a type which is freed are corrupted. 

During debuging i have seen several places where it happens but had some debug output gibberish so i am not sure that i do not just see ghosts.
I can not tell if after the GpgME::initializeLibrary the stack is already corrupted. (See debuglog2.txt) 
Afaik the stack gets corrpted qgepegemebackend's check function after which
I have always seen the crash in the destructor of gpgme++'s error type with one of the most distinct error logs beeing ( debuglog3.txt )

Created attachment 59173 [details]
Possible corrupt stack after gpgme::initializeLibrary

I've tried this with a libgpgme compiled with i568-mingw-msvc and i686-w64-mingw and also with the binaries from the gpg4win-dev package from gpg4win 2.0.1 (June 2010)

Kleo was always compiled with i686-w64-mingw 
I have not tested libkleo i568-mingw-msvc with gpg4win 2.0.1 (June 2010) so it is still possible that this is a compiler Problem. 

(To be clear the -w64 only stands for mingw-w64 it is the 32 bit compiler from this project)

A smaller test case for this is kcmshell4 kmail_config_security this does not
crash but in the debugger you get exceptions and on the debug output you get
loads of "Invalid Parameter passed to C Function" warnings.

Even with a mingw.org build and the same gnupg versions which were proven to work in the Windows packages from 2009 this error still persists.
So the probability is quite high that there is some problem in kdepimlibs/kdepim that causes this problem.

The things tested were:
mingw.org build of kdepim with gpg4win 2.0.1 and according gpgme.
mingw.org build of kdepim with gpg4win 2.1 and git master gpgme

This might be our old friend -mms-bitfields which gpg(me) sets and Qt doesn't. I don't think  KDE does either, still. I've tried to convince the Qt people to set it before, with no luck. The solution is to either build gpgme without (and dependencies) or build Qt and everything up with the flag.

Could also be something unrelated, of course.

Patrick: Do we build gpgme with the cmake buildsystem with -mms-bitfields ?
I can try to build a gpg4win-dev package without that option. 
I wonder why this was no issue then last year or so but maybe there was some structure changed in a way that it is now affected by the different packaging. This should be worth looking into. Thanks for the hint.

Patrick Spendrin wrote the following test to produce a crash:

#include <gpg-error.h>
#include <gpgme++/context.h>
int main(int argc, char** argv) {
        GpgME::Context* ctx;
        GpgME::initializeLibrary();
    ctx = GpgME::Context::createForProtocol(GpgME::OpenPGP);
        return 0;
}

ok, I played around with this bug (I tried the kmymoney one, but it is essentially the same). The problem does *not* happen because of the gpgme stack, but instead it is a compiler bug: if you hand over a std::string over dll boundaries, a heap corruption will take place. I talked to the mingw-w64 people and they pointed me to the --enable-fully-dynamic-string option when building the compiler (check gcc -v to see the build flags). That one is definitely missing from the sezero build we use at the moment (it is a heavily backported gcc 4.4.7). I tried out the 4.5 build from sezero which doesn't seem to set this flag as well. A small test program compiles fine and doesn't crash anymore, I cannot try out with kdepim nor with mymoney since my build fails in phonon due to a cxx_abi* linker issue. I'll add an updated test program for the heap corruption in a minute.

*** Bug 281341 has been marked as a duplicate of this bug. ***

Git commit ef20860bc9df147c31a57caea1786020dd46bb87 by Andre Heinecke.
Committed on 04/01/2012 at 16:32.
Pushed by aheinecke into branch 'enterprise'.

Begone foul fiend! (Enable crypto again)

    Thanks to Patrick Spendrin's research on BUG 269808 we have
    now found the reason why gpgme++ kept crashing.

    For more details on this see:

D  +0    -24   portage/enterprise5/kdepim-e5/disable-crypto-backend.patch
M  +0    -2    portage/enterprise5/kdepim-e5/kdepim-e5-20110117.py

http://commits.kde.org/emerge/ef20860bc9df147c31a57caea1786020dd46bb87

Wow,great work guys!