Here's the logfile with all the errors (guru debug level) vanilla 2.1.10

After some time spending fighting with the build tools of gnupg (cross compile
for windows under debian) I managed to build the installer with my patched
file.

Most important: The most common error thrown is the 0x8010001e
(E_SERVICE_STOPPED) This is the important one. The other error 0x8010001d
(E_NO_SERVICE) is only thrown in the transition from ok to stopped. So only
sometimes.

This was my process:

git clone git://git.gnupg.org/gnupg.git
cd gnupg
git checkout tags/gnupg-2.1.10
./autogen.sh
cat ../0001-scd-Fix-removal-of-unplugged-usb-readers.patch | patch -p1
sed -i -e 's/^SELFCHECK=1/SELFCHECK=0/' build-aux/speedo.mk
make -f build-aux/speedo.mk w32-installer

I've created new logfiles (vanilla 2.1.10 und patched 2.1.10) to show the
difference and confirm that it'S actually working now :-)

I'm okay with signing off the commit. I can test this for Windows 8.1 or 10,
my only problem is that I'm not able to compile gpg for windows right now. Or
are there instructions somewhere on how to achieve this?

Thank you again.

I think that Windows 8 (and later) changed the PC/SC service. The service is
only available when smartcard is there, and after the removal, it returns
PCSC_E_NO_SERVICE error. This is not expected for current code.

I'm applying your patch with my comment like above. Do you agree to put the
line in the commit log?:

   Signed-off-by: Daniel Hoffend <dh@dotlan.net>

I don't have Windows 8 machine. So, I leave this issue as testing.

No, I just installed version 2.1.10 (which included your mentioned fix). But the
error still applies.

In my case the smartcard reader never gets closed, cause the error thrown by the
pcsc/scd gets only mapped to a general_error which does not result in
removing/closing the reader interface.

I've the feeling that we've to take a closer look at the errors thrown (at least
those 2 in my patch). Maybe there're even more possible events.

If you like I can upload the debug log of scdaemon 2.1.10 ... (if that helps).

Somehow I don't have any issues when running linux, this bug applies to windows
only atm. Maybe it's just that windows is throwing different errors or events
compared to linux.

Thank you for the bug report with log.

It could be related to the bug which was just fixed:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=f42c50dbf00c2e6298ca6830cbe6d36805fa54a3

I'm backporting this to 2.0.x.

After looking at the gnupg 2.0 branch I would say the patch could be applied
to the 2.0 and 2.1 branch to fix the issue in both branches stable/modern
since both version are affected (tested with 2.1.9 and 2.0.29 from gpg2win)

The "migration succeeded" despite of the I/O errors smells fishy. Can you
please delete the "gpg-v21-migrated" file in
C:/Users/xxxxx/AppData/Roaming/gnupg/ and try again with a log file?

I won't call that leaking memory.

With your fix it no longer crashes. But you are leaking memory in case
default_homedir returns allocated memory from read_w32_registry_string or
standard_homedir with a successful call to w32_shgetfolderpath.

As the result should be cached in the static variable this is probably not an
issue..

I just pushed a fix.

The problem with gpgme is that we need to stop the Explorer if we want to update
or uninstall gpgme. Given tha we can't use gpgex with the portable version
anyway, I think it is better to keep the existing code and don't switch to gpgme.

Using gpgme would be nice of course to avoid duplicated functionality (this same
stuff is also implemented in gpgol although without the bug) but remember that
we would then also need a x64 version of gpgme.

The bug is pretty obvious. I consider to rewrite it by calling gpgconf
--list-dirs to get the home directory. This would be simliar to what we do in
gpgme. Or well, we could link to to gpgme to and make use of its higher level
interface.

Thanks for looking at this. If you like I could test your fixes. I currently
have a build setup and a test setup where I can reproduce the crash.

Btw. Maybe I don't understand c++ enough but afaik this just makes no sense and
is broken:

  try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}

should be rather something like:
if (dir)
name = string(dir) + "\\S.uiserver";

I have some fixes sitting here in my local repo. I need to check them.

Closing this as a duplicate of T1516

Duplicate of T1516

Sorry for the delay, the passphrase is 512 characters long (now I should change
it after publishing that here ;-)) and just ascii characters.

With GnuPG 1.x, Enigmail takes care of presenting the passphrase dialog.
With GnuPG 2.x GnuPG does it of its own. For that it spawns a small tool
called pinentry which asks for the passphrase. We actually have several
versions of that pinentry. The one you are using is based on Qt (a toolkit) and
has a limit of 256 bytes for the passphrase. The limit may actually be lower if
you are using non-ascii characters, but I can't see how that value is not
sufficient.

How long is your passphrase and does it contain many non-ascii characters (e.g.
Umlauts)?

Hello, Thank you for your reply.

I used the gpg4win-2.2.1.exe binary which I downloaded from gpg4win.org

The popup I mentioned is the screen that asks me for my password when I try to
open an encrypted mail in my mailbox via thunderbird/enigmail. See the
screenshot. In the newer gpg version this popup is replaced by a prompt screen
that says pinentry and will allow only for shorter passwords.

I understand that my password is exceptional long, as I still was (and maybe
still am) a beginner on the encrypted mail part. But backwards compatibility
seems pretty important in the case of encrypted mails and passwords to decrypt them.

What do you mean by "openpgp popup"?

Which installation options did you used whethn installing gpg4win? Depending on
the version you get a different pinentry version - we have a qt based one, a GTK
based base, and a very simple native windows pinentry.

For diagnostic reasons: could you try with Kleopatra as well?

Maybe this is relevant:
I only installed gpg, gpgEX and GPA from the GPG4Win package.

Using gpg.exe on the command line works perfect.
I can en- and decrypt files and sign and whatnot.
Only gpgEX is affected.

The crash happen regardless of what I did before. Usually I use Q-Dir as file
browser. When I trigger a gpgex action via context menu in one Q-Dir OR Windows
Explorer the program (the one I used) crashes.

I set GNUPGHOME as a user variable via Windows' Extended System Settings.

I followed Bernhard's suggestion and attached the GpgEX debug log.

Please provide a proper bug report so that we are able to replicate this. For
example, how did you set GNUGHOME, what process have been started before that
etc. A complete run trough on how to exhibit the bug would be a appreciated.

Thanks for asking again, I did not remember that GPGex was missing from the
compendium.

It works similiar to GpgOL, see
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gpgex.git;a=blob_plain;f=README;hb=HEAD
and in German:
http://lists.wald.intevation.org/pipermail/gpg4win-users-de/2013-
August/000593.html

Actually, I can't.
The link you provided leads to a site with some general infos.
There is another link into the compendium with infos about
some GPG4Win components but not a single word on gpgex.

So HOW do I provide some more diagnostic output?

Fixed in d3f20e7. Applied patch to gpg4win as well.

In the backtrace gpa_backtrace2.png you can see that the crash happens:
https://bugzilla.gnome.org/show_bug.cgi?id=696232

If we apply the patch it no longer crashes, but as the error handling in that
patch is just to abort, the text is not copied into the clipboard and we do not
get an error in GPA.

So still some more debugging why invalid utf-8 data is sent from gpa.
As the data worked on comes from GPA and "should" be valid utf-8

Backtrace attached. Sorry that it is an image but windows was blocking me from
copying the gdb output to the clipboard.

Libgcrypt does not support 64 bit Windows yet. In particular do not use it even
if it would build and run fine. MSVC is not a supported build platform anyway.