I'm currently using the TCP output of NXLog (v2.9.1347) to ship Windows Server 2008 R2 eventlogs to Logstash (v1.4.2) in JSON format; lately I found that NXLog crashes if Logstash has been unavailable for some time and then became available, although it ships a few logs before crashing.

This event is logged in the eventlog:

Faulting application name: nxlog.exe, version:, time stamp: 0x54fedd1a
Faulting module name: ntdll.dll, version: 6.1.7601.18247, time stamp: 0x521ea8e7
Exception code: 0xc0000005
Fault offset: 0x0005e8d1
Faulting process id: 0x4e4
Faulting application start time: 0x01d0a2b5080df49c
Faulting application path: C:\Program Files (x86)\nxlog\nxlog.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 7ebdb4d7-1036-11e5-909f-005056a30012

To reproduce the issue, just have NXLog ship logs to Logstash and then stop Logstash for about an hour then start it, NXLog crashes soon after.

Any idea what might be causing this?

AskedJune 20, 2015 - 9:07pm

Answer (1)

It is possible that this is not related to the om_tcp reconnection but some other bug getting hit when processing the data that has piled up while logstash was down. Can you post your config?

Comments (4)

  • dev667's picture

    Here it is:

    #define ROOT C:\Program Files\nxlog
    define ROOT C:\Program Files (x86)\nxlog

    Moduledir %ROOT%\modules
    CacheDir %ROOT%\data
    Pidfile %ROOT%\data\nxlog.pid
    SpoolDir %ROOT%\data
    LogFile %ROOT%\data\nxlog.log
    #LogLevel DEBUG
    #NoCache TRUE

    <Extension json>
        Module    xm_json

    <Extension charconv>
        Module xm_charconv
        #AutodetectCharsets utf-16, utf-32, iso8859-1, windows-1252

    # Nxlog internal logs
    <Input nxlog-internal>
        Module im_internal
        Exec $EventTime = integer($EventTime)/1000; to_json();

    <Input eventlog>
        Module      im_msvistalog
    # For windows 2003 and earlier use the following:
    #   Module      im_mseventlog
        Exec $EventTime = integer($EventTime)/1000; to_json();

    <Output out>
        Module      om_tcp
        Host        logstash-server
        Port        5140

    <Route 1>
        Path        nxlog-internal, eventlog => out

  • adm's picture

    Can you test without im_msvistalog or perhaps with a single im_null instance only to see if the crash is related to the reconnection?

  • dev667's picture

    You might be right; I tried im_null without any crashes, and also im_file instead of im_msvistalog which continued forwading the logs once Logstash became available without crashing.