Unexpected Reboots on SQL Servers

To determine the root cause of the unexpected reboots and the installation of the old 2015 KB on the SQL servers, use the Windows event logs on each affected server to reconstruct exactly what happened and when.

1. Identify whether each reboot was normal or unexpected
   • On each server, open Event Viewer → Windows Logs → System.
   • Filter for the following Event IDs to classify the reboot type:
     • Normal reboot pattern:
       • 1074 (User32) – which process/user initiated the restart and why.
       • 13 (Kernel-General) – OS is shutting down.
       • 6009 (EventLog) – OS version at startup.
     • Unexpected reboot pattern:
       • 41 (Kernel-Power) – system rebooted without a clean shutdown (crash, hang, or power loss).
       • 6008 (EventLog) – previous shutdown was unexpected.
   • If Event ID 1074 is present near the reboot time, check the process name, user, and reason to see if Windows Update or an SCCM/management client initiated the restart.
2. Confirm whether the 2015 KB installation triggered the reboot
   • Still in System log, filter for Event ID 19 (WindowsUpdateClient) around the reboot time:
     • Event 19 indicates: “Installation Successful: Windows successfully installed the following update: Security Update for Windows (KBxxxxxxx)”.
   • Correlate timestamps:
     • If Event 19 for the 2015 KB appears shortly before a reboot, and a 1074 event shows a restart initiated by a Windows Update or management client process, this indicates the KB installation required and triggered the reboot.
3. Check for unexpected reboot plus bugcheck or power loss
   • If there is no 1074 but there are:
     • 41 (Kernel-Power) and 6008 (EventLog) → reboot was not a planned shutdown.
     • 1001 (WER-SystemErrorReporting) → “The computer has rebooted from a bugcheck…” and a MEMORY.DMP path.
   • In that case:
     • A bugcheck (blue screen) or power/hardware issue caused the reboot, and the KB installation may have been pending or applied around the same time.
4. Build a full reboot and update history around the first occurrence
   • To see when this behavior started and what changed just before it:
     • In System log, filter for Event IDs 12, 13, 19, 41, 1001, 1074, 6008, 6009, 7045.
       • 12 (Kernel-General) – OS started.
       • 6005 (EventLog) – Event log service started.
       • 6009 (EventLog) – OS version at boot.
       • 7045 (Service Control Manager) – new service installed (for example, a driver or management agent that might be related to SCCM or another update mechanism).
   • Use this timeline to:
     • Identify when the first unexpected reboot occurred.
     • See whether the 2015 KB, a new driver, or a management client/service (Event 7045) was installed shortly before the issue.
5. Map findings back to SCCM activity
   • Once the exact KB number, installation time (Event 19), and reboot initiator (Event 1074 or 41/6008) are known for each server, provide this timeline to the SCCM team:
     • If 1074 shows a ConfigMgr/Windows Update process as the initiator and the time matches a deployment from the “older” collection, that confirms SCCM as the trigger.
     • If 41/6008/1001 dominate with no 1074, focus on OS/hardware/driver stability and bugcheck analysis, and treat the KB as coincidental unless its installation time aligns exactly with the crash.
6. When to engage Microsoft Support
   • Engage Microsoft Support with:
     • Exported System and Application logs covering at least several hours before and after each reboot.
     • Exact Event IDs and timestamps for 19, 41, 1001, 1074, 6008, 6009, and any 7045 entries related to SCCM or update agents.
     • The specific KB number from the 2015 update and confirmation from SCCM of the collection/deployment that targeted these servers.
   • This evidence allows support to validate whether the reboot was:
     • A planned restart due to the KB installation via SCCM/Windows Update, or
     • An unexpected reboot (bugcheck/power) coinciding with or caused by the update.

References:

• Troubleshoot unexpected reboots using system event logs
• Review Event IDs 13, 41, 1074, 6008, and 6009 to determine reboot types
• Review Event IDs 19, 41, 1001, 1074, and 7045 for the causes of reboot
• Unexpected reboot examples