Windows Service doesn't always start: networking not available?

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Install the service in the usual way on (many) managed PCs via standard 
scripted software deployment means;
2. Restart those PCs;
3. Observe that on *some* PCs, the service does not start.  On others it starts 
just fine.

(I appreciate that these aren't technically steps to 'reproduce' the problem, 
but that's what I'm seeing)

What is the expected output? What do you see instead?

On a subset of PCs, the Windows Service evtsys does not start: it shows the 
message "Aug 20 13:51:18 PCNAME Connecting socket for LogHost1 (LOGHOST:514) 
failed with error 10051: A socket operation was attempted to an unreachable 
network." in Event Log. (Where PCNAME and LOGHOST are sanitized for this report)

In this state, the PC boots without starting the evtsys service.  It can be 
started manually without any issue after logging in, however.

What version of the product are you using? On what operating system?

Windows 7 64-bit, evtsys 4.4.3 64-bit

Please provide any additional information below.

The above happens in a Windows 7 environment where the Windows PCs are 
identical software-wise (deployed from the same single disk image), but may 
have different hardware.  I'm speculating, but it seems that for some PCs, 
networking starts too late which is why evtsys shows an "unreachable network" 
error.

I tried working around the problem in various ways:

1. Manually adding a dependency on the 'netlogon' service, presuming that this 
should require the network to be sufficiently 'up' for evtsys to see the 
network, but this didn't seem to help;

2. Switching the service startup from 'Automatic' to 'Automatic (delayed)': 
this worked in the sense that evtsys started OK, but all the messages from 
early in the boot process are valuable to me and these are missed out if I 
configure it this way.

Any advice on how I can configure this differently to work around these issues?

Original issue reported on code.google.com by omega.am...@gmail.com on 20 Aug 2012 at 1:41

[GoogleCodeExporter]

I made a (not perfect) workaround. It works but ideally the service could 
probably be started earlier in the boot secuence to capture more of the events.

1/ I added "sc start EvtSys" to the GPO startup-script. This starts the service 
as group policy processing runs.

2/ Edited the EvtSys service startup type to auto-delayed, to catch the rare 
event that group policy processing fails for some reason.

Original comment by ibrahim....@gmail.com on 8 Oct 2012 at 9:22

[GoogleCodeExporter]

I'm going to be putting a lot of effort into the utility over the next two 
months, so hopefully I can find a proper solution to the issue. I still haven't 
been able to replicate it, but I'll try doing some research on the underlying 
cause. Thanks for posting your "workaround".

Original comment by sherwin....@gmail.com on 8 Oct 2012 at 6:03

[GoogleCodeExporter]

Sounds great that the project is "Alive".

I have a machine where the problem is consistent.

It's a virtual Windows Server 2008R2, 64-bit, running on ESXi. It's a member 
server with the "Remote Destop Services" feature activated (Terminal Services).

If you need beta-testers I would like to give a hand!

Original comment by ibrahim....@gmail.com on 9 Oct 2012 at 9:08

[GoogleCodeExporter]

As I mentioned in my original report, I can find some systems on which the 
problem can be reproduced too.  Am happy to help test new code, certainly.

Original comment by omega.am...@gmail.com on 9 Oct 2012 at 9:43

[GoogleCodeExporter]

Original comment by sherwin....@gmail.com on 16 Oct 2012 at 4:38

• Changed state: Started

[GoogleCodeExporter]

Hi,

Any progress? 

I've reviewed the source code partially, when SyslogOpen() fails, does it 
notice the service manager that it can't start?

Original comment by the.warl...@gmail.com on 23 Jan 2013 at 4:16

[GoogleCodeExporter]

I believe if SyslogOpen fails it will terminate the process. I will have to 
check. The simplest thing would be to add a loop that continue to retry until a 
connection can be made.

-Sherwin

Original comment by sherwin....@gmail.com on 25 Jan 2013 at 4:55

[GoogleCodeExporter]

Seeing this on multiple Windows 7 machines in a network with a pfSense based 
router. After startup, an event appears in the viewer, saying "A timeout was 
reached (30000 milliseconds) while waiting for the Eventlog to Syslog service 
to connect."

I have no idea how 30 seconds timeout could possibly happen, as the machine has 
network connectivity as soon as it arrives at the Windows desktop. However, if 
the connection is attempted too early and never retried...

Original comment by b...@dhampir.no on 12 Feb 2013 at 7:21

[GoogleCodeExporter]

The Netlogon service only applies if you are authenticating with a domain 
controller, so for most people that will not trigger Eventlog to Syslog.  There 
are, however, a number of other network services that you can make Eventlog to 
Syslog dependent upon, and it will work just fine on system startup without 
adding any of these delayed start hacks.  You will not get all the early boot 
logging, yes, but the only way you could get that information is if Eventlog to 
Syslog was buffering those logs until a network connection became available.

In order to add a services as a dependency, you need to modify the 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\EvtSys\DependOnService 
key, and add the short name for the service on a new line (after eventlog). 
Some services that you could add as dependencies that would work are (with 
their short names in parens):

Network Location Awareness (NlaSvc)
Server (Server)
Network List Service (netprofm)

Basically anything that happens after Remote Procedure Call and Network Store 
Interface seems to work fine.

Original comment by nikil.me...@gmail.com on 21 Jul 2013 at 6:58

[GoogleCodeExporter]

Hi all,

great input. I have had same problem on all of my Win7 machines, that the 
service doesn't start automatically when booting. And there is no feedback from 
the service to the Service Manager that there was a failure.
Any way I have tested with the dependencies as Nikil wrote. 
@Nikil: Thanks, was very helpful.
But I experienced that in my case I need some more. At least the Group Policy 
and the network has to be there as well. So I used the 5 Services within 
dependecies and it worked for me:

Network Location Awareness (NlaSvc)
Server (LanmanServer)
Network List Service (netprofm)
Group Policy Client (gpsvc)
Network (netman) 

I have a German Windows, so I don't know excat names of services, I hope the 
short names will do.
I could set start type to automatic.. delayed is not needed.
Definitely some events will be lost, but better than delayed start..
Anyway a cache of events and delay send to syslog server will be great 
improvement.

@Sherwin: if you develop some store&forward mechanism, please let me now. I 
will do also some beta-testing.

Anyway the event2syslog  is great stuff.

Regards

Original comment by kappa.my...@gmail.com on 30 Jul 2013 at 4:23

[GoogleCodeExporter]

Hello, has any progress been made on this issue? I have a Windows 8.1 machine I 
am trying to use this software with.

It works on automatic (delayed start), but I have tried making dependencies on 
all of the services recommended in this thread and I still have the issue of 
timeout after 30 seconds.

The other relevant configuration information is that I am on a domain, trying 
to connect evtsys to a server on my intranet. This may have to do with all of 
the stuff that microsoft has done to try and speed up boot time. It seems like 
this is not the only windows service that has trouble on my machine because of 
network issues, but it is the only one that just stops and won't retry if it 
fails.

Original comment by jbray.1...@gmail.com on 6 Dec 2013 at 1:43

[GoogleCodeExporter]

I ran into this same problem and seemingly solved it by adding LanmanServer as 
a dependency, based off of this suggestion: 
http://stackoverflow.com/questions/10855290/which-windows-service-ensures-networ
k-connectivity

I also agree with the sentiment expressed here (and in the link) that best 
practice would be to update the business logic to handle lack of network, 
whether from early start-up or other disconnection, gracefully, probably with 
some sort of local cache/queue, sending the messages when able.

Original comment by ri...@umn.edu on 2 Jan 2014 at 11:38

[GoogleCodeExporter]

I spoke too soon. After some additional testing I discovered Netman in addition 
to LanmanServer is required and seemingly sufficient.

Original comment by ri...@umn.edu on 3 Jan 2014 at 12:10