I'm troubleshooting a Dell PowerEdge T340 running Windows Server 2016 that has hard-reset repeatedly since late August. Every incident produces Kernel-Power 41 with BugcheckCode 0, no bugcheck parameters, no Event 1001, and no dump files. Event 6008 confirms an unexpected shutdown, but the iDRAC lifecycle and system-event logs remain completely silent.
The unusual part is the timing. The shutdowns occur roughly every 728.47 minutes—about 12 hours, 8 minutes, and 28 seconds—with only 1.2 minutes of total variation across twelve events. During one weekend the server stayed up for five intervals and then failed, suggesting a free-running timer that continues across reboots and can skip several expirations rather than a normal Windows scheduled task.
A heartbeat logger writing and flushing every five seconds shows the system is healthy immediately before each failure: approximately 56 GB of free RAM, 346–352 MB of nonpaged pool, no disk queue, and stable handle and thread counts. There is no apparent hang or degradation; the machine simply disappears and then boots normally.
I have investigated the PSUs, thermals, iDRAC watchdog and SEL, Dell OMSA, Windows Update, scheduled tasks, VSS, MySQL memory usage, the disconnected NIC, the CMOS battery, and CrowdStrike. The server uses dual PSUs and an APC Back-UPS XS 1500M connected through USB. The UPS reports healthy current conditions, but I do not have historical transfer data. The BIOS and iDRAC firmware are several revisions behind and are now being updated.
The main remaining possibilities seem to be a UPS self-test or power-transfer event, a firmware or hardware watchdog, a storage or PCIe-controller issue, or another device below Windows with a persistent timer. I plan to bypass the UPS, test each PSU on separate power sources, and try leaving the system in firmware or an alternate boot environment during a predicted failure. What could generate such a precise free-running interval, and how much should the absence of an iDRAC SEL entry be trusted as evidence against a power event?
4 Answers
I would bypass the APC first. Back-UPS units can briefly transfer or produce an output disturbance during self-tests even when their current status looks healthy. A dual-supply server makes this easy to test: connect one supply directly to known-good mains and leave the other on the UPS, then reverse or remove the UPS entirely if necessary. A failed transfer may not always leave a useful server-side record, especially if power disappears too abruptly for the BMC to log it.
The fastest isolation test is to remove both the operating system and the UPS from the experiment. Put one PSU on a known-good wall circuit and the other on a separate, reliable source if available, then leave the server sitting in BIOS or boot a simple USB environment. If it still resets at the same elapsed time, Windows and its applications are effectively ruled out. Also check whether manually rebooting the machine resets the interval or whether the original schedule remains anchored.
Leaving it at the BIOS screen is a useful low-load test because it removes network traffic, drivers, scheduled tasks, and application activity while still exercising the platform hardware.
Do not assume the 728-minute value proves the trigger itself runs on that exact schedule. The timestamp in an unexpected-shutdown event may be based on a periodic heartbeat or last-known write rather than the precise instant power vanished, so the apparent interval can include a fixed delay or rounding. Also compare the calendar carefully: the missing weekend failures suggest an external weekday-only action, such as a managed PDU, building equipment, cleaning activity, or another device sharing the circuit. Watching the server and UPS during the predicted window, or recording them with a camera, may reveal a transfer, alarm, or human action that the logs miss.
The precision points more toward firmware, a watchdog, storage, or a PCIe device than toward memory pressure or ordinary Windows maintenance. Update the T340 BIOS, iDRAC, Lifecycle Controller, storage controller, drive, backplane, NIC, and any nonstandard PCIe-card firmware. Check the Lifecycle Controller logs separately from the basic SEL, and review the BIOS settings for OS Watchdog Timer or Automatic System Recovery. A platform watchdog or controller fault can reset the machine without producing a Windows bugcheck.
If storage patrol read or another controller background scan runs on a long interval, correlate its start and completion times with the failures. A controller or drive firmware crash could make the entire PCIe path disappear before Windows can record anything.
If the failures stop with the UPS removed, run a controlled UPS self-test afterward and watch both the server and iDRAC. That should distinguish a scheduled UPS event from a general power or server problem.