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?

works with Gpg4win 2.2.0. But there is a failure after decrypting folder with
umlauts: see gpg4win wald issue #6451
(https://wald.intevation.org/tracker/index.php?func=detail&aid=6451&group_id=11&atid=126)

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.

Let's assume that the problem was in the glib library and has been fixed in the
meantime. I will soon release a new Gpg4win version with the latest stable glib
version. Feel free to reopen if you still encounter this problem.

Yeah sure, I meant "NOT a problem".

Yes I know what you mean. But without locking you will never be able
to get it right.

As you noted there is actually a problem with Libgcrypt under
Windows. In Libgcrypt we lock the seed file and thus the fatal error
is the right thing to do. But.....

  #ifdef __GCC__
  #warning Check whether we can lock on Windows.
  #endif
  #if LOCK_SEED_FILE

Thus we should implement locking for Windows. The problem here is
that there is no portable advisory locking in Windows. And frankly our
fcntl locking approach does not work on all Unices either and worse it
does not work if the home partition is on certain remote file systems.

The only solution I see is to employ the new dotlock code from GnuPG
here. It is slower than fcntl locking but very portable.

I don't think we will fix this in gpg 1.4.

This is known but a problem from a security POV.

I suppose you mean "NOT a problem"? I think it might be a problem in
opportunistic encryption scenarios if gpg encryption failures caused by
random_seed access conflicts are ignored like failures caused by missing keys.
But usually it's just a nuisance like any other randomly failing program.

The non-locking read is on purpose - if it works: okay. Otherwise we
re-generate a seed file.

I see that the code tries to tolerate access conflicts, but there's still a race
condition if the random_seed file is truncated between fstat() and read(). The
read() error handling is incomplete. Maybe this pseudo-patch explains best what
I mean:

diff -ru gnupg-1.4.12/cipher/random.c gnupg-1.4.12/cipher/random.c

• gnupg-1.4.12/cipher/random.c 2012-01-24 09:45:41.000000000 +0100

+++ gnupg-1.4.12/cipher/random.c 2012-09-18 19:47:54.449578800 +0200
@@ -492,11 +492,17 @@

    do {
	n = read( fd, buffer, POOLSIZE );
    } while( n == -1 && errno == EINTR );

• if( n != POOLSIZE ) {

+ if( n == -1 ) {

	log_fatal(_("can't read `%s': %s\n"), seed_file_name,strerror(errno) );
	close(fd);
	return 0;
    }

+ else if ( n == 0 ) {
+ ... handle like sb.st_size == 0
+ }
+ else if ( n != POOLSIZE ) {
+ ... handle like sb.st_size != POOLSIZ
+ }

     close(fd);

Yes, we could do the file locking

Proper locking would be the ideal solution, but a better read() error handling
would already be sufficient to avoid the sporadic fatal errors on random_seed
accesses.

and iirc, we do this in libgcrypt (GnuPG-2).

I'm just checking this and ... sorry, no. The gpg2.exe from Gpg4win 2.1.0 shows
the very same error:

note: random_seed file is empty
note: random_seed file is empty
Fatal: can't read `C:/Dokumente und
Einstellungen/jechternach/Anwendungsdaten/GnuPG /random_seed': No such file or
directory

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
note: random_seed file is empty

This is known but a problem from a security POV. The seed file is a cache. If
the seed file can't be read a new one is created. Right, there might be a
performance issue but at least on Windows this is not as severe as on certain
Linux systems.

The non-locking read is on purpose - if it works: okay. Otherwise we
re-generate a seed file. Yes, we could do the file locking and iirc, we do this
in libgcrypt (GnuPG-2).

The error on short reads is also on purpose. We want those 600 bytes at once
and nothing else. If another process is writing the seed file we may see the
short reads. But in this case there is no clear answer waht to do - thus we
assume the "no seed file" case.

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.

Thanks, Werner, for your reply and your suggestions. I'll have a look at the
GPGME solution.

This is a long standing problem. Usually GPG is used by other utilities and
they exepct utf-8. Thus we would habe to detect the plain use of the console
and then dosomething about it.

No response to my last message. It seems to be an IPC bug and not related to
GPG given that other GUIs don't have these problems.

Fixed in dirmngr and also in GnuPG trunk. Patch for gpg4win created.

ping, it's important for gpg4win.

No info received - assuming everything is fine now.

I have not tried with differnt volumes, but the current gpg4win release works
fine with regards to admin and normal user. Harry, can you please test if this
is still an issue, or if you have moved on from Windows 2000, I will just close
the report.

No time to look into this. Hints on how to fix this are of course welcomes

And why you won't fix it?

[In may previous message I meant "gpg does not _wait_ for the end ..."]

I noticed that the status of this issue was changed to resolved and was
wondering if that meant that it will work in a future version of gnupg or if
it means that nothing will/can be done for the Windows version, i.e. a disk
write will be required each time, and the issue is just closed?

According to the manual and also by a quick look at the code of
g_file_get_contents(), which is called before g_utf8_validate, it should never
return TRUE and store NULL at content. Thus I can't figure the real reason for
this by only looking at the code. Needs more debugging.

Could be the installation to H. In the last 2.5 years we fixed many bugs that
could have caused this. We should test this with current versions and close if
not reproducible.

The first version of dirmngr that worked on any Windows reasonably well is
1.0.2. Versions before that had a multitude of issues, so I am closing this
report. If there are particular problems with current dirmngrs on 64 bit Vista,
please report them with the appropriate level of details.

Meanwhile we have greatly improved gnupg on w32. See www.gpg4win.org. Thus it
makes no sense to care about this old bug anymore. If the problem still
persists with Gpg4win 1.9.9, please re-open this bug.

We did quite some work on the Widnows stuff and the forthcoming 2.0.10 should
fix a couple of problems. There is a weel known problem with card chnage
detection on all platforms. We are still working on that one. As that is also
tracked by other reports (probably several), I close this one.

We are anyway going for GnuPG-2 on Windows. With the gpg-agent framework, there
is no more need for application specific passphrase entries. Thus I close this
bug and wait until it gets a new life in Pinentry ;-).