Page MenuHome GnuPG

Closed, ResolvedPublic


GpgEX is crashing Windows Explorer (per window) when opening the context menu
for any File.

GpgEX has no executable details and as such no publisher or version information.
As of it's date it has been created on 28.05.2013, from a downloaded package
Gpg4win v2.1.1.

Actually I like the UI, but because I was digging now an hour or two around
importing new Bundesnetzagentur certificates (wich I discovered now using Google
on and not using the builtin ldap search), I'd like to say that
it is way too damn complicated to get started with these applications!



Event Timeline

metadings added projects: gpgex, Bug Report.
metadings added a subscriber: metadings.

Please give more details. What OS are you using, what other explorer extensions
are used and so on. Do you use other software which might have been build using
gcc (mingw)?

Regarding the UI: Welcome to the strange world of S/MIME and X.509
certificates. I can't count the hours I spend looking for a certain certificate

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:


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)

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

It is possible that GpgEx picks up wrong versions of the GCC support dlls
libstdc++-6.dll and libgcc_s_sjlj-1.dll. They might have been installed by some
other software. Thus my question whether you use any software which has been
build with gcc.

The problem is that we are not able to define the order of DLL searches for the
explorer plugin. Experiments with a Manifest didn't reveal a solution either.

For that reason the next version will link those support libraries static. The
new 64 bit GpgEX posted to the devel list already uses this.

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:


DynamicSig[22].Name=Zusatzinformation 1
DynamicSig[23].Name=Zusatzinformation 2
DynamicSig[24].Name=Zusatzinformation 3
DynamicSig[25].Name=Zusatzinformation 4

Last week I posted a revamped version og GpgEX 64 and 32 bit to the gnupg-users
mailing list. You may want to try that one. It is also possible to build a
complete new Gpg4win installer with gpgex 32 and 64 bit. We will release a beta
next week.

Most DLLS and exe files have versioninfos - some where not instantly displayed
due to missing language information.

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?)

werner claimed this task.

We released a new Beta yesterday and due to a build glich we will update that
today. Thus I close this bug.

The mailman passwords are by design weak and the web page explictly mentions
that you should not use a valuable password. The admin can anyway see everything.