Most DLLS and exe files have versioninfos - some where not instantly displayed

due to missing language information.

Yes, I'm also used to discover that "the" version info of an assembly must be
EN-US (or default) regardless of the what I wanted to.

I'm now subscriber to the mailing list, although I hate these mailman mailing
lists, because I found out that they're storing passwords in plaintext in their
database (isn't that weird when developing strong encryption tools?)

That could it be. I got an error log that I deemed not to be that interesting,
however it says

LoadedModule[147]=C:\Program Files\GNU\GnuPG\gpgex.dll
File change date: 28.05.2013 18:46

LoadedModule[148]=C:\Program Files\GNU\GnuPG\libgcc_s_sjlj-1.dll
File change date: 28.05.2013 16:34

LoadedModule[149]=C:\Program Files\GtkSharp\2.12\bin\libstdc++-6.dll
File change date: 27.11.2012 06:56

Actually I found some version string in the binary libpngxxx.dll using Notepad,
but no luck in these three files. It would be very useful if you would compile a
VERSIONINFO structure into your binaries. On Windows, using Explorer and also
tools like SysInternals's autoruns (where I disabled the ext) this is really
helpful to find fast and easily a version and publisher info (when overlooking
the system for malicious files, that's a good indicator).

Found a good answer on stackoverflow:

http://stackoverflow.com/questions/598633/gcc-on-windows-set-description-field-
of-c-executable

-----

Sig[0].Name=Anwendungsname
Sig[0].Value=explorer.exe
Sig[1].Name=Anwendungsversion
Sig[1].Value=6.1.7601.17567
Sig[2].Name=Anwendungszeitstempel
Sig[2].Value=4d6727a7
Sig[3].Name=Fehlermodulname
Sig[3].Value=libstdc++-6.dll
Sig[4].Name=Fehlermodulversion
Sig[4].Value=0.0.0.0
Sig[5].Name=Fehlermodulzeitstempel
Sig[5].Value=50b4b868
Sig[6].Name=Ausnahmecode
Sig[6].Value=c0000005
Sig[7].Name=Ausnahmeoffset
Sig[7].Value=0007aed1
DynamicSig[1].Name=Betriebsystemversion
DynamicSig[1].Value=6.1.7601.2.1.0.768.3
DynamicSig[2].Name=Gebietsschema-ID
DynamicSig[2].Value=1031
DynamicSig[22].Name=Zusatzinformation 1
DynamicSig[22].Value=ef31
DynamicSig[23].Name=Zusatzinformation 2
DynamicSig[23].Value=ef31968b50046133f9fdd00fc890a1a4
DynamicSig[24].Name=Zusatzinformation 3
DynamicSig[24].Value=1008
DynamicSig[25].Name=Zusatzinformation 4
DynamicSig[25].Value=1008829529ade9726731888a07d92dae

Here I found some documents that may help, but I don't know if this is actually the
crash failure.

How to Digitally Sign Microsoft Files (.exe, .cab, .dll, .ocx, .msi, .xpi)
http://www.thegeekstuff.com/2010/03/microsoft-digital-signatures/

Making Your Application UAC Aware
http://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware

PS: Only other non-default extensions I'm using are 7-Zip, FileZilla, Hermann
Schinagl's LinkShellExtension and Malwarebytes. However disabling GpgEx.dll solved the
problem.

I'm running Win7 x86 HomePremium German. I installed by a mingw release by
extracting somewhere, but don't use it. I'm usually using VS2010 for C#/Web.

The issue was (the unsigned) gpgex library, registered for File and Directory
context menus in Windows Explorer. Without disabling the extension, this rendered
Windows Explorer unusable.

For users will be no other option than uninstalling.

Look here for actually valid certificates:
http://www.trustcenter.de/en/infocenter/root_certificates_601.htm

Gruß