Hi, There
As I knew, what’s really happening that you're facing to
- Those 7023/7036 logs mean FCOM’s own comms channel dies first, so its services stop.
- The reboot is triggered by something else right after (Windows Update, a scheduled task, a watchdog, UPS/AV/backup agent, etc.). So you have two issues: a nightly comms drop and a separate reboot trigger.
So how to find the culprit ?
1. Who asked to reboot? Event Viewer > System > look for Event 1074 around 00:36 (it names the process).
- If it’s
UpdateOrchestrator/Windows Update → see “Fixes” below.
2. What died before FCOM? Filter 00:30–00:45 for .NET Runtime, Schannel, IIS/HTTP, NetTcpPortSharing, MSMQ, SQL, licensing/watchdog. One of these usually blips right before FCOM 7023.
3. Tasks at that time Task Scheduler (enable history): check UpdateOrchestrator, Automatic Maintenance, AV/backup/vendor tasks scheduled ~00:30–00:45.
Then try these PowerShell as Admin
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} -Max 10 |
ft TimeCreated,Message -Wrap
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,6006,6005} |
select TimeCreated,Id,ProviderName,Message
And these fixes that usually stop this cold
- If Windows Update is rebooting it: Set GPO > No auto-restart with users logged on = Enabled, and extend Active Hours to cover midnight; or set a proper maintenance window.
- If a dependency recycles (IIS/Net.TCP/MSMQ/SQL/licensing): Move that job away from 00:30–00:45, make FCOM services Auto-Restart (Recovery tab), and add a short delayed auto-start so dependencies come up first.
- If cert/time sync is the cause (Schannel/time jumps): Fix NTP (single reliable source), align certificate renewal to a safer window, or do a controlled service recycle after renewal.
- If AV/backup is starving it: Reschedule heavy scans/backups; add exclusions for FCOM binaries/work dirs per vendor docs.
- If a vendor watchdog/licensing task reboots the box: Update/relax the watchdog, or apply the vendor patch that fixes channel faults.