I have a Dell PowerEdge T340 running Windows Server 2016 that has been hard-resetting at remarkably regular intervals. Every shutdown produces Kernel-Power 41 with BugcheckCode 0, all bugcheck parameters set to 0, and an Event 6008 for the unexpected shutdown. There are no blue screens, dump files, or memory dumps.
The actual shutdown timestamps, taken from the Event 6008 message text rather than the Event 41 timestamp written during the next boot, are separated by roughly 728.4 minutes—about 12 hours, 8 minutes, and 28 seconds. Across twelve events the total variation is only about 1.2 minutes. One weekend gap was 3,641.7 minutes, almost exactly five periods, while the server remained running the entire time. That makes this look like a free-running timer that sometimes completes without resetting the machine, rather than a normal scheduled task that starts over after every reboot.
The server stops instantly. A forced-flush heartbeat logger showed flat memory usage with about 56 GB free, stable nonpaged pool, no disk queue buildup, and steady handles and thread counts right up to the final sample. The last heartbeat was followed by the next boot roughly three minutes later, consistent with POST and startup rather than a preceding hang.
I have already checked the obvious possibilities: both power supplies report healthy status, temperatures and throttling are normal, the management controller has no SEL entries for any of the crashes, watchdog and automatic recovery features are unavailable or disabled, Windows Update was inactive around every event, and security software found nothing. I also disabled the only promising 12-hour repeating scheduled task, but the resets continued at the same interval. Other scheduled tasks, VSS, MySQL memory use, the network adapters, and the CMOS battery do not match the timing or evidence.
The system is connected to an APC Back-UPS XS 1500M over USB. Current UPS readings look healthy, but I do not have historical transfer or self-test data. The BIOS and management-controller firmware are several revisions behind.
My next test is to bypass the UPS and run the server directly from mains power, possibly reconnecting the USB cable and UPS afterward in stages. What could generate a free-running period of approximately 728.4 minutes? Could an APC self-test, a power sag, a BMC or PSU firmware issue, or another device on the circuit explain an immediate reset with no bugcheck and no management-controller event? How much confidence should I place in the silent hardware event log?
5 Answers
The unusually precise period may be a coincidence caused by something external rather than a normal 12-hour task. Check whether the longer gaps correlate with weekends, holidays, staffing schedules, building maintenance, or a device that is only operated during business hours. A managed UPS or PDU could also be cycling the wrong outlet group. I would keep those possibilities open even though the timing looks too precise for ordinary HVAC equipment.
I would not treat the empty management-controller SEL as proof that power is innocent. A very brief voltage dip, a UPS transfer, a switched outlet group, or an external PDU event might kill the server without leaving a useful SEL record. Check the UPS's own event and self-test history, and investigate whether any building equipment or managed power outlet could be cycling on a similar schedule.
It is possible that the apparent 728-minute interval includes a recurring operation followed by an approximately eight-minute action or timeout, rather than being a single timer set to 728.4 minutes. Check for power-policy actions, outlet-group schedules, UPS self-tests, firmware tasks, and any appliance or PDU automation that could run every twelve hours. I would also rule out expired or malfunctioning licensed management software, although that seems less likely than the UPS or power path.
The cleanest next experiment is to remove the UPS completely: connect the server directly to mains, disconnect the UPS USB cable, and observe it for at least one predicted interval. If the resets stop, add the USB connection back first, then put the server back on UPS power. With redundant supplies, you could also put one PSU on mains and one on the UPS, but avoid changing several things at once. Replace or swap the power cords during the test if possible.
Analyze the Application and System logs immediately before each shutdown, not just Windows Update. Also check the UPS logs if that model exposes them. A self-test or transfer could be scheduled independently of Windows and would explain why the interval survives reboots. Updating the BIOS, iDRAC, and related firmware is also worthwhile after collecting the current evidence, since a firmware timer or controller bug is one of the few explanations that fits the symptoms.
That is a useful angle. The long gap did line up with a weekend, although the later holiday weekend did not produce the same pattern, so the correlation is not conclusive. I will compare it with building and maintenance activity rather than assuming the timer is entirely server-local.