dirmngr is meanwhile an integral part of GnuPG. The old 1.1 dirmngr is entire obsosolete and won't do what gpg expects from it. To better diagnose the problem you can do this:

• kill the running dirmngr process
• run in a command window
  
  dirmngr --server -v

Are there any error messages displayed? No: Enter on the command line "getinfo version". Does it respond with a version number?

No, there isn't any error message or output, and it not accept any input.
Here is a GIF capture, but may not helpful.

By add parameter "--debug-level guru" i can got the only one output "dirmngr[15880]: enabled debug flags: x509 crypto memory cache memstat hashing ipc dns network lookup extprog", after this, same as above.

EDIT:
I can confirm no running dirmngr process, no third part av or related program installed, except Windows defender

Can you please try again with the standard shell (and not the power shell)?

I experience this same behavior, standard shell. Both with admin, windows live based account and local, non-admin account.

I have exactly the same problem on my Windows 10 machine. I am using bitdefender as virus scanner, but it doesn't work no matter if it is active or not. Windows is fully updated and I am using gpg4win 3.0.3.

Kleopatras self-test shows a few minutes after trying to start that there is a problem with dirmngr and Kleopatra only starts after killing dirmngr with the taskmanager. If I try to start dirmngr manually like @ariane tried it's just hanging without any output. I tried cmd instead of powershell. But it's just the same problem.

Something more I can do on my side to give you more information to find the problem?

//EDIT: Windows 10 Pro 64 Bit, the user has administrator permissions, but UAC is enabled. Didn't try without UAC yet.

I, too, have this problem. I have Windows 10 Pro 64-bit with BitDefender Total Security. My first reaction when this wasn't working was to disable all functions on BitDefender. That didn't help, so I ran dirmngr as admin in cmd (I despise PowerShell) without any luck. I created a non-admin user and ran it in there, again without luck. I've come up dry. No logs, no output, and no answers. Is there anything shy of downgrading dirmngr that will make this work? Has there been any progress as to figuring this out?

@werner here's the only output I get:

dirmngr[23440]: Note: no default option file 'C:\Users\Timberwolf\AppData\Roaming\gnupg\dirmngr.conf'
dirmngr[23440]: enabled debug flags: ipc dns network

after that it just sits there indefinitely and there is nothing in my firewall logs.

Add

--debug-wait 3

to the above command line. Do you see the waiting for debugger message ? If so it might stop in the initialization of the threading code. We can debug that then,

dirmngr -v --debug ipc,dns,network --log-file - --server --debug-wait 3

Produced the exact same result. No extra wait messages or anything.

So I used a debugger to see if I could garner any additional info. Here's the log:

New command line: "C:\Program Files (x86)\GnuPG\bin\dirmngr.exe" --debug-wait 3 -v --debug ipc,dns,network --log-file - --server
DLL Loaded: 74870000 C:\Windows\SysWOW64\imm32.dll
DLL Loaded: 75F80000 C:\Windows\SysWOW64\combase.dll
INT3 breakpoint "TLS Callback 1 (libgpg-error-0.dll)" at libgpg-error-0.6B4924A0 (6B4924A0)!
INT3 breakpoint "TLS Callback 2 (libgpg-error-0.dll)" at libgpg-error-0.6B492450 (6B492450)!
INT3 breakpoint "TLS Callback 1 (libassuan-0.dll)" at libassuan-0.65A8D1F0 (65A8D1F0)!
INT3 breakpoint "TLS Callback 2 (libassuan-0.dll)" at libassuan-0.65A8D1A0 (65A8D1A0)!
INT3 breakpoint "TLS Callback 1 (libgcrypt-20.dll)" at libgcrypt-20.65679FE0 (65679FE0)!
INT3 breakpoint "TLS Callback 2 (libgcrypt-20.dll)" at libgcrypt-20.65679F90 (65679F90)!
INT3 breakpoint "TLS Callback 1 (libksba-8.dll)" at libksba-8.64DA7F80 (64DA7F80)!
INT3 breakpoint "TLS Callback 2 (libksba-8.dll)" at libksba-8.64DA7F30 (64DA7F30)!
INT3 breakpoint "TLS Callback 1 (libnpth-0.dll)" at libnpth-0.6A803D10 (6A803D10)!
INT3 breakpoint "TLS Callback 2 (libnpth-0.dll)" at libnpth-0.6A803CC0 (6A803CC0)!
INT3 breakpoint "TLS Callback 1" at dirmngr.0047AEB0 (0047AEB0)!
INT3 breakpoint "TLS Callback 2" at dirmngr.0047AE60 (0047AE60)!
INT3 breakpoint "entry breakpoint" at <dirmngr.EntryPoint> (004014E0)!
DLL Loaded: 761D0000 C:\Windows\SysWOW64\shell32.dll
DLL Loaded: 752F0000 C:\Windows\SysWOW64\cfgmgr32.dll
DLL Loaded: 750A0000 C:\Windows\SysWOW64\SHCore.dll
DLL Loaded: 75620000 C:\Windows\SysWOW64\windows.storage.dll
DLL Loaded: 754B0000 C:\Windows\SysWOW64\shlwapi.dll
DLL Loaded: 77510000 C:\Windows\SysWOW64\kernel.appcore.dll
DLL Loaded: 75510000 C:\Windows\SysWOW64\powrprof.dll
DLL Loaded: 77CF0000 C:\Windows\SysWOW64\profapi.dll
Thread 740 created, Entry: ntdll.77E63880
DLL Loaded: 74250000 C:\Windows\SysWOW64\mswsock.dll

After it loads mswsock.dll, it just hangs on an entry point. Further investigation is that the main thread is "paused" by "UserRequest" as seen here: http://prntscr.com/j46c61

Did that help any?

I'm having the same issue. I read somewhere that it's likely caused by using an online Windows account to login with. So I converted to local log in. Issue persists. As a test, I've just set up a VM with a local account set up at install, and GPG4Win works perfectly fine. So I'm guessing that there may be an issue which stays in the files system caused by online account users. I'm not a programmer and have no idea how or where to look to see what's causing it and how to fix it though.

That actually makes sense, because it works fine on my laptop, where it's been a local account from the start, but it's broken on my desktop where it was originally a MS account, but is now local.

@RAmbidge are you able to further test this by using a VM with a MS account? I don't have the means right now, or I'd do it myself.

@tinkerwolf This is weird... I've reinstalled my PC from scratch with an initial account set as local, and was able to set up GPG4Win perfectly fine for the first time on my PC (as I did in the VM). So, set up a VM with an initial account set up from an online account. GPG4Win started up fine... I am now really confused!! Somewhere within the getting set up with an online account, something has to be happening that interferes with dirmngr..
Will investigate further.

Was anyone successful in debugging dirmngr? I'm having the same issue. The dirmngr process gets stuck, no output at all, and this causes Kleopatra to get stuck waiting for it. I can only run Kleopatra after I have killed the dirmngr process. If I understand correctly I still need this process for network-related functionality, so I would need to fix it if I want to use all functions.

(I never setup a Microsoft account on my PC, so I doubt it is related to the account type in this case)
I also tried clearing the executable for firewall access, with same results.

Hi, Has anyone found a reason why that happens. I run into the same behavior on my Windows 10 1803 computer. I have Gpg4win version 3.1.3 freshly installed and dirmngr hangs. Thanks and best regards, Peter

Hi,

I'm also seeing the same behaviour on a freshly installed Windows 10 1809 with Gpg4win v3.1.4. Have to kill dirmngr from task manager to be able to get into Kleopatra.

Has anybody discovered a fix for this issue? I'm running Win 10 Pro with Gpg4win v3.1.5. Dirmngr is still not executing and just hangs.

I'm thinking of how to move this forward.
The problem is that we (the developers) can't reproduce this at all and the debug output does not show anything.

My idea to get more information about this would be to track the syscalls so could someone here please:

• Install Process Monitor from: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
• When starting that program it will ask for filters. Add one for "Process Name" "is not" "dirmngr.exe" then "exclude"
• start dirmngr from the command line

-> At this point you should see some output

• Save the file with: "Events displayed using current filter" in "Native Process Monitor Format"
• Put the resulting file in a zip archive (it might be large) and attach the archive here.

It should look like this:

Process Monitor tracks windows system calls and this might show us a syscall that hangs or at least give us a better idea when dirmngr starts to hang.

The log will contain your user name and might contain some information about your system, but nothing private.

If you don't want to have it published here you can also send it to me directly to aheinecke@gnupg.org (

Thanks!

Done, See attached

Perfect, thanks.

I see some strangeness:
A TCP Connect: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050
and TCP Send: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050

As the last calls in the log. This should not happen.

At the same place in my working log I have:
TCP Reconnect esus-Virtual:59098 -> esus-Virtual:9050
TCP Reconnect esus-Virtual:59098 -> esus-Virtual:9150

"esus-Virtual" is my host name. The connect is test connection to the TOR port (9050) and afterwards to the TOR Browser Port.

Please try to start dirmngr with the option:

--no-use-tor

This will disable this check / connect.

I do not understand yet how the name resolution there could be broken. In the past it was possible on windows to redirect "localhost" to a different IP. This caused e.g. Kleopatra not to start. But as far as I know this is fixed in updated Windows 7 versions and all later versions.

We'll review the code there. Please let us know if "--no-use-tor" helps.

Running with the --no-use-tor results in output ending with OK Dirmngr 2.2.11 at your service, attached is the procmon output , to clear up one thing q4master.idsoftware.com points to 127.0.0.1 in my hosts file (in addition to localhost also pointing to 127.0.0.1), but it seems the issue is with the tor check

Apparently i had a ASUS Wi-Fi go process listening on that port (even though i thought had uninstalled it), killing the process also allows dirmngr to start

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

That process is the one i killed which is part of Asus Wi-Fi Go

In T3381#121973, @madhon wrote:

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

That process is the one i killed which is part of Asus Wi-Fi Go

I see, it is part of the ASUS AI Suite. So anybody running an ASUS motherboard who installs the ASUS tools might be affected.