Outbound call failure after server reboot/failover/recovery

[giwm]

We have our main server and a warm spare backup with Enterprise licensing. The last two months we've rebooted the main server for Windows updates. When the main server reboots, we failover to the backup server. Once back up, we recover back to the main server. This is all automated and has worked without issue in the past. In February and now in March, outbound calling will fail (internal will work) until we restart the SIP Server service.

I thought it was a fluke last month so didn't look to much into it. Today I checked event viewer and I see:

• Five PostgreSQL errors with event ID 0, the description ending with "FATAL: terminating connection due to administrator command"
• One PostgreSQL error with event ID 0, the description ending with "ERROR: canceling statement due to user request"
• One Application Error with event ID 1000 with details:
  • Faulting application name: 3CXSLDBServ.exe, version: 15.5.6847.0, time stamp: 0x5a8fe987
    Faulting module name: SL.dll, version: 2.0.27552.0, time stamp: 0x5a8fe8d4
    Exception code: 0xc0000409
    Fault offset: 0x0000000000089c0c
    Faulting process id: 0x7990
    Faulting application start time: 0x01d3b1c7afccd43b
    Faulting application path: C:\Program Files\3CX Phone System\Instance1\Bin\3CXSLDBServ.exe
    Faulting module path: C:\Program Files\3CX Phone System\Instance1\Bin\SL.dll
    Report Id: 95b079f0-21c8-11e8-80d5-00155d030258
    Faulting package full name:
    Faulting package-relative application ID:
• One nginx error with event ID 0 with details:
  • Child process [31416 - C:\Program Files\3CX Phone System\Bin\nginx\nginx.exe "-pC:\Program Files\3CX Phone System\Bin\nginx" ] finished with 0
• One Service Control Manager error with event ID 7034 with details:
  • The 3CX PhoneSystem Nginx Server service terminated unexpectedly. It has done this 1 time(s).

Looking back to the last time this happened (2/7/18), the sequence is almost exactly the same, with only a change in the number of the first set of PostgreSQL errors.

As I look back further, this seems to have been going on with nearly every reboot. We just never made a correlation before.

We are running on Windows Server 2012 R2 Datacenter.