I have a Dell PowerEdge T340 running Windows Server 2016 that has hard-reset 15 times since late August. Every incident produces Kernel-Power 41 with BugcheckCode 0, Event 6008, no BSOD, no dump, and no corresponding iDRAC SEL entry. The server is healthy right up to the reset: memory, nonpaged pool, handles, threads, disk queue, and temperatures remain stable, and the machine stops responding instantly rather than hanging first.
The unusual part is the timing. The shutdowns are roughly 728.4 minutes apart—12 hours, 8 minutes, and 28 seconds—with only about 1.2 minutes of total variation. One weekend gap was exactly five periods, even though the server remained running, suggesting a timer that continues independently of Windows and does not reset after reboot. The failures also appear to occur on weekdays rather than weekends.
I have already investigated power supplies, thermals, iDRAC watchdog and SEL logs, Dell OMSA, Windows Update, scheduled tasks, VSS, memory pressure, the disconnected NIC, CrowdStrike, the CMOS battery, and the Secure-Boot-Update task. The server uses dual PSUs connected to an APC Back-UPS XS 1500M, but I do not have historical UPS transfer or self-test data.
The main possibilities I am considering are an APC self-test or power disturbance, Dell BIOS/iDRAC/PSU firmware or a hardware watchdog, a storage or PCIe device with a recurring firmware timer, or an external electrical event. What would produce such a precise free-running interval, and how should I isolate the cause?
5 Answers
Run the machine outside Windows for at least one complete interval. Leave it sitting in the BIOS, or boot a diagnostic USB environment, with the network disconnected and application services absent. At the same time, use a different power source. If it still resets at the same elapsed time, Windows and installed software are effectively ruled out; if it does not, start removing recent agents and drivers, especially endpoint security and vendor hardware software.
The weekday-only pattern makes me suspicious of something outside the operating system: a managed PDU, building power equipment, HVAC or generator testing, cleaning activity, or another device sharing the circuit. A free-running internal timer does not naturally explain why several expected ticks were skipped over weekends. Check the UPS and circuit directly, and see whether the iDRAC itself reboots or loses uptime when the server does.
Be cautious about calling the Event 6008 timestamp the exact instant of power loss. Windows records that information during recovery and some shutdown-time fields can come from a periodic heartbeat, so the displayed time may have limited precision. The repeated interval is still highly suspicious, but compare it with UPS event timestamps, iDRAC uptime, BIOS/Lifecycle logs, and an external clock or camera before assuming the 8-minute offset is a real execution duration.
Update the T340 BIOS, iDRAC, Lifecycle Controller, PSU, storage-controller, and drive firmware before chasing exotic timer theories. The versions listed are several revisions behind, and firmware bugs involving watchdogs, PCIe, storage patrol reads, or platform resets can cause an immediate reset with no Windows bugcheck. Also check the Lifecycle Controller hardware log separately from the iDRAC SEL and inspect the BIOS OS Watchdog Timer and Automatic System Recovery settings.
If the reset is caused by a firmware watchdog, disabling the relevant watchdog temporarily is a useful diagnostic, but do it only with an out-of-band recovery plan. Updating firmware is still the better long-term fix.
The fastest first test is to bypass the UPS completely, or put one server PSU on a known-good wall circuit and leave the other on the UPS. A Back-UPS self-test or a brief transfer can drop a server without giving Windows time to log anything, and the iDRAC may not record every kind of power interruption. If the failures stop, replace or remove the UPS from the setup; for a server, a properly sized online or Smart-UPS is generally more appropriate.
I would also physically observe the UPS at the next predicted time. Its display, clicks, self-test indicator, or load change could provide more evidence than the host logs.
A clean manual reboot at a known point is another useful experiment. Compare whether the next reset occurs 728 minutes after the reboot or at the previously predicted wall-clock time; that distinguishes an uptime timer from an external schedule.