This page could benefit from more info and editing, please help to improve it

There are several places where someone finds information about how to trouble shoot a crypto application problem.

TODO: link to the sections in the gpg4win compendium and other documentation.

For problems with adele see EmailExercisesRobot.

for users

If the downloaded package seems to be broken, please check the integrity of the downloaded package, by validating the checksum. You find a List of the checksums and a guide for *Nix systems here. For Windows 10 users, there is the Get-FileHash operator, which came with PowerShell 5. The syntax is: Get-FileHash FileToHash.ext -Algorithm SHA1 | Format-List. Windows users with Windows Vista and above can use the certutil program. The syntax is: certutil -hashfile FileToHash.ext sha1. Older Windows systems have to download a Windows Patch which provides this functionality.

for service technicians

Goal is to build up a valid understanding of the problem, how it came to be and possible solutions.

1. If the problem is with GpgOL, try the operation with GpgEX or Kleopatra, to exclude Outlook's influence. Note that if GpgEX/Kleopatra works, you have a fallback solution to just work via files and send them by attachment, so can can still use crypto, but with less comfort.
2. If GUI frontend applications fail, try to do the operations on the command line. This way you can often exclude that the problem is within the frontend. And you sometimes get additional helpful messages.
3. Look at or activate and look at additional diagnostic output. (http://gpg4win.de/doc/en/gpg4win-compendium_29.html, TODO link or refer to specific section in the official docs.) There are many ways where additional output can be found or enabled.
4. Try to reproduce, sometimes a different installation or a different computer gives you an idea about the difference between a running and a problem case.
5. Precisely check the version numbers of components.
6. Check general operating or usage issues. Things like a full harddrive or wrong filesystem permissions.

Kleopatra crashes/does not start

Background: Kleopatra (for Gpg4win 2.3) is build on top of Qt4 and KDE Platform 4 windows port. It uses localhost TCP ports a d-bus process to communicate with other components.

1. Start Kleopatra manually on the command line (use cmd.exe and "cd" to the installation directory one step above the "pub" dir), see for messages there.
2. Either activate the Kleo log (see general link above in the diagnostic step)
3. or try to see the diaognistic messages that the operating system receives, you can use DebugView
4. Looking at how the libraries are resolved with Dependency_Walker may give a hint too, if Kleopatra does not start at all or complains about missing dlls.
5. If you get a crash and no further information, you could try to get a backtrace, e.g. with a gdb build for windows.

Windows > 8 and Server 2012 Task Scheduler Problems

GnuPG uses (as suggested by Microsoft and usual) %APPDATA%\gnupg to store data on Windows. When launched from the Task Scheduler %APPDATA% is not always set to the correct users directory. (If you launch it with system privileges it is another place altogether). GnuPG as a result is unable to find the Keys or configuration in the directory Windows provides.

This is a known Windows bug. See the Knowledge Base article Or This technet discussion

Instead of the Workaround mentioned in the knowledge base article GnuPG provides you with the option to set the Home directory as part of the command. (--homedir) Which makes it easy to workaround that bug.

For example:

  gpg --homedir c:\Users\aheinecke\AppData\Roaming\gnupg --encrypt -r <recipient> <file>

Would ignore the broken value of %APPDATA% and use the keys stored in c:\Users\aheinecke\AppData\Roaming\gnupg instead. Make sure access rights are set accordingly of course so that this works with the user the Scheduled task runs under.