Solution - Responder - Windows Service Fails to Recover from a Crash

Version 2



    The Responder Windows Service is unable to start again if it crashes.  The event log contains the following error:


    2016-02-16 15:10:20,034 MainThread WARN Miner.Responder.Processors.ServerApplication (null) - Application is already running... (Press <Enter> to exit)

    2016-02-16 15:10:20,081 Miner.Responder.LineDisplayService 2716 StdOut Reader ERROR Miner.Responder.WindowsService.Program (null) - Program Miner.Responder.LineDisplayService (2716) exited unexpectedly
    StartTime = 2/16/2016 3:10:19 PM
    ExitTime = 2/16/2016 3:10:20 PM
    ExitCode = 1

    Console Output:
    Application is already running... (Press <Enter> to exit)
    Application is already running... (Press <Enter> to exit)

    2016-02-16 15:10:20,112 30 ERROR Miner.Responder.WindowsService.ProgramGroup (null) - Error while starting program
    Miner.Responder.WindowsService.ProgramFailedToStartException: Program (0) failed to start. ---> Miner.Responder.WindowsService.ProgramFailedToStartException: Program (0) failed to initialize.
      at Miner.Responder.WindowsService.Program.Start()
    — End of inner exception stack trace —
    at Miner.Responder.WindowsService.Program.Start()
      at Miner.Responder.WindowsService.ProgramGroup.StartProgram(Program program)




    We had implemented a lock into the Windows Service that checks for and prevents more then one Line Display to run at a time. Another part of code checks to ensure that items from a previous service are not still running and proceeds to shut them down. These two checks need to have their orders reversed to prevent the service from failing to start. In our testing, it appears the Microsoft Message Queuing service is allowed to be started before the network interface has completely initialized. This causes the Message Queuing service to bind to the loopback IP address instead of the network address. Responder may be the only application affected by this, unless other applications use Message Queuing.



    The code has been changed in 10.2.1c to remedy this. All versions can get the service to start by termnating the Line Display task from Task Manager. This allows the Windows Service to start, and it will issue its own shutdown for any processes that were left behind. Microsoft provides a hotfix that will delay the connection for MSMQ that is included in SP1 of Windows 7 / 2008R2. You can also set the Startup on the Message Queuing to Delayed Startup. This allows every service to start before Windows begins starting any services that are delayed.