Page MenuHome GnuPG

dirmngr won't start on Windows 10 with admin level account
Closed, ResolvedPublic

Description

Hello,

I'm using gpg4win 3.0.0-beta292 on Windows 10 Version 1703, when i'm trying launch kleopatra, a "cmd window" named "C:\Program Files (x86)\GnuPG\bin\dirmngr.exe" launched but seems freeze, kleopatra self-test dialog will not show before i kill the dirmngr process. There isn't any error message from dirmngr.
I have try run dirmngr with "dirmngr --verbose --debug-level guru" but nothing printed, process hanging without any error message, and will not exit or crash.
I have try create a new account with admin privileges, same issue. but it will start with a start privileges account.

After several times reinstall and remove configure file, i replaced dirmngr by the older one extract from gpg4win-2.3.4.exe, then everything work. by manual launch, i can see message "OK Dirmngr 1.1.1 at your service".

I don't know what the version of dirmngr shipped with gpg4win-3.0.0-beta292, because it not work, and i can't get any info from file attribute

Event Timeline

werner added a subscriber: werner.

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?

Please kill all existing dirmngr instances and don't run any programs which will trigger it to be started (e.g. Kleopatra). Then run in a _standard_ shell (cmd.exe):

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

after some debug output you should see

OK Dirmngr 2.2.5 at your service

There you can enter commands (try HELP). But I guess you want get that far. Do you see any output at all? Does your firewall software block or log any events (dirmngr might send UDP packets to DNS servers)? Are you using the right dirmngr? (run "dirmngr --version")

@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

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.

aheinecke added a subscriber: aheinecke.

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:

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

Thanks you very much for your help! I think we have it. \o/

I can reproduce this under GNU/Linux now, too. If something listens on port 9050 but won't respond dirmngr hangs.

Regarding q4master.idsoftware.com pointing to 127.0.0.1 that might explain why it shows there. It could just be a display issue in ProcMon, if it tries to replace ip's with hostnames and does a reverse lookup for 127.0.0.1 that might result in above name.

Now, what I would find very interesting: What is listening on that port? Maybe that is some software which all affected users here have also installed. You can find that out by running "netstat -a -b" in an elevated command line and then look for the entry for port 9050.

@werner I think there needs to be some timeout added to socks5_connect in libassuan (or earlier).

To reproduce:

nc -l -p 9050
# in another terminal:
dirmngr --server

I'm assigning this issue to you as it is reproducible on GNU/Linux.

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.

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

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.

Just as a note: To workaround this you can also place "no-use-tor" into %APPDATA%\gnupg\dirmngr.conf (you might need to create that file) %APPDATA% expands to something like "c:\users\yourname\appdata\roaming"

We need to fix it of course and I hope that we will get this done for the next version.

Oops. Assignee removal was an accident. Sorry for the noise here ;-)

aheinecke raised the priority of this task from Normal to High.Jan 24 2019, 7:32 PM

I want to have this fixed for the next release so prio high.

Sorry but you will also receive a mail after this that I've added it to the gpg4win-3.1.6 target.
A noisy day.

aheinecke added a subscriber: gniibe.

gpg4win 3.1.6 is released which contains this fix.

Thanks @gniibe