Page MenuHome GnuPG

Update gpg4win 2.3.3 -> 3.0.1 leaves DirMngr Unable to Start (Error in Win10 Event Log)
Closed, ResolvedPublic

Description

On Windows 10 (build 15063.726) after update from gpg4win 2.3.3 to 3.0.1 the old DirMngr service fails to start causing windows to log an error in the event log. e.g.

Log Name:      System
Source:        Service Control Manager
Date:          11/25/2017 8:14:45 PM
Event ID:      7000
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      elite
Description:
The DirMngr service failed to start due to the following error: 
The system cannot find the file specified.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
    <EventID Qualifiers="49152">7000</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8080000000000000</Keywords>
    <TimeCreated SystemTime="2017-11-26T02:14:45.541373200Z" />
    <EventRecordID>7119</EventRecordID>
    <Correlation />
    <Execution ProcessID="788" ThreadID="952" />
    <Channel>System</Channel>
    <Computer>elite</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">DirMngr</Data>
    <Data Name="param2">%%2</Data>
    <Binary>4400690072004D006E00670072000000</Binary>
  </EventData>
</Event>

The error log is correct, DirMngr is no longer running when checking system config -> services. If DirMngr is not supposed to be running with 3.0.1, then the entry attempting to start it wasn't removed on update. If it is supposed to run with 3.0.1 -- that's a problem.

This doesn't visibly effect the behavior of gpg4win and is more of just a log annoyance as long as DirMngr not running is the intended behavior. If so, it looks like a registry cleanup is overlooked when installing 3.0.1.

Just thought I would pass it along.

Here is a bit of additional information. The old dirmngr seems to have used AppData/Local, while the new is using AppData/Roaming. At least manually starting dirmngr.exe results in the following:

dirmngr[10532]: error opening 'C:\Users\david\AppData\Roaming\gnupg\dirmngr_ldapservers.conf': No such file or directory
dirmngr[10532]: permanently loaded certificates: 63
dirmngr[10532]:     runtime cached certificates: 0
dirmngr[10532]:            trusted certificates: 63 (62,0,0,1)
dirmngr[10532]: failed to open cache dir file 'C:\Users\david\AppData\Roaming\gnupg\crls.d\DIR.txt': No such file or directory
dirmngr[10532]: creating directory 'C:\Users\david\AppData\Roaming\gnupg\crls.d'
dirmngr[10532]: new cache dir file 'C:\Users\david\AppData\Roaming\gnupg\crls.d\DIR.txt' created
# Home: C:\Users\david\AppData\Roaming\gnupg
# Config: [none]
OK Dirmngr 2.2.3 at your service

It still isn't shown in System Configuration -> Services?

Note: this problem wasn't one I originally noticed as a gpg4win/gnupg problem. This is a log error I noticed while troubleshooting the dang windows 1709 Fall Creators Update mess and the gpg4win update just happened at about the same time. So I have copies of DirMngr running in Services pre-3.0.1 update, and then the error post-3.0.1 update.

Details

Version
3.0.1

Event Timeline

aheinecke added a subscriber: aheinecke.

Dirmngr should no longer run as a system service. It's now started with user privileges on demand. The

dirmngr[10532]: error opening 'C:\Users\david\AppData\Roaming\gnupg\dirmngr_ldapservers.conf': No such file or directory

Is Ok and nothing to worry. Everything looks fine except that the System Service was somehow not unregistered during the upgrade to 3.0 It should have been so it may be a bug in the installer.

aheinecke claimed this task.

I tuned down the error message. I don't think there is a problem here anymore.

We use "error ..." and "failed to ..." interchangable. The German translation even uses the same term for both.
Thus I think it would be better to keep the old diagnostic but show it only in --verbose mode.

Changing from log_error() to log_info() is correct, though.