4
responses

Every now and then I get reports of logs not reporting. I investigate and 99.9% of the time, it is due to a loss of connectivity to the log server due to an nxlog crash. Typically, it is due to a faulting module, per Windows Event Viewer.

OS - Windows Server 2012 R2 Datacenter

NXLOG Version - How do I check?

Event Viewer ::

Faulting application name: nxlog.exe, version: 0.0.0.0, time stamp: 0x54fedd1a
Faulting module name: libapr-1-0.dll, version: 0.0.0.0, time stamp: 0x54fedd1a
Exception code: 0xc0000005
Fault offset: 0x00015190
Faulting process id: 0x160
Faulting application start time: 0x01d1b804aaa52028
Faulting application path: D:\Program Files (x86)\nxlog\nxlog.exe
Faulting module path: D:\Program Files (x86)\nxlog\libapr-1-0.dll
Report Id: 79778f7a-2701-11e6-80c2-00155d590419
Faulting package full name: 
Faulting package-relative application ID: 

 

Is this a known issue? Are there ways to prevent this from happening?

Thank you!

AskedJune 1, 2016 - 6:38pm

Answers (2)

Faulting on libapr libray sounds like that the NXLog fails at the transport layer, that it could be the case if you are using an output module that uses TCP protocol like om_http or om_tcp.

I am using NXLog for some years now and from my experience the most stable community version for Microsoft Windows platform is v2.8.1248

If your projects are small and requirements dont't change CE could suffice.

But in complex enterprise environments the EE edition is the only solution. With EE you have to ask NXLog for support and possible workarounds for the  affected customer and not always try to investigate yourself ( as I did with CE ) "what went wrong with my configuration?" when an unexpected problem happens.