Share via

Some computers keep shutting down uncontrolled

David 0 Reputation points
2026-05-28T14:12:37.5333333+00:00

Hello.
I am an IT Administrator in a mid sized company who is about to rip out his hair out of frustration.
We have a super weird issue, where several Computers, all loaded with the Same Windows Image through a SCCM Task Sequence, randomly, without a noticable pattern, shut off for no reason.
There is no statement in the Event Viewer, other than the System is executing the Shutdown.exe with the Code 0x800000ff per request of the SYSTEM\User32 and sometimes "OurDomain""User"
That is it.
Sometimes the Shutdown reason even varies entirely.

We have a self made application running on all affected computers, yet not all computers that run the application are affected. Some of them have never had this problem. The application logs also do not show anything out of the ordinary, whenever a system shuts down.

I have easily spent a hundred hours trying to find a pattern that could lead me to the reason. I could not come up with anything.
What I have tried:

  • Updated BIOS and Windows
  • Disabled the configured shutdown-task in the task scheduler
  • Disabled our Antivirus software
  • Checked GPOs
  • Patched the custum application (though it does not seem to be connected)

Since we are talking about roughly 150 affected clients resetting them with a new image is out of the question. We do not have the capacities for that. And since the shutdowns happen randomly it is hard to replicate, once I have tried a solution attempt. So i can just wait, if it happens..

Thank you in advance for helping.

Good day!

Windows for business | Windows Client for IT Pros | User experience | Other

5 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. David 0 Reputation points
    2026-05-28T14:30:34.5666667+00:00

    Steps 1 and 2 have already been done. It is alway Event-ID 1074 and always the same reason code 0x800000ff.
    Furthermore I could not find any difference in the "SYSTEM..." and the "DOMAIN..." induced shutdowns.
    Step 3, 4 and 5 will be the next thing to try.
    Step 6 is not applicable
    Step 7 has been done and is found to be unlikely the issue.

    i will update.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. Daphne Huynh (WICLOUD CORPORATION) 660 Reputation points Microsoft External Staff Moderator
    2026-06-09T02:28:03.2966667+00:00

    Thank you for your kindly update!

    That changes the picture quite a bit and in a useful way. The event signature matches the classic “ghost shutdown” pattern on Windows 10/11 and Windows Server 2016/2019/2022. This is not a crash, but a programmatic shutdown triggered from within the user’s session. A few important facts about this exact signature:

    RuntimeBroker.exe is not the cause. It brokers UWP/Modern app requests. When any in-session process calls a shutdown API (e.g., ExitWindowsEx) without a proper reason, Windows often logs Event ID 1074 under RuntimeBroker.exe with reason 0x0 (Other/Unplanned).

    The message “Restart/Shutdown initiated by the user from the Start → Power menu” is misleading. It simply means something called the same APIs as the Start menu (ExitWindowsEx, InitiateShutdown, WMI Win32Shutdown, or WinRT ShutdownManager)—not that a user clicked Shut Down.

    Since the system shuts down daily, you can reliably capture it:

    1. Enable Process Creation auditing with command line (captures shutdown.exe)

    Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success

    Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events = Enabled

    After the next shutdown, in the Security log filter for Event ID 4688 in the minute before the 1074. The Creator Process Name + Process Command Line will name the parent.

    2. Enable the WMI-Activity Trace (catches the Win32Shutdown / WMI variant)

    Event Viewer → View → Show Analytic and Debug Logs.

    Navigate to Applications and Services Logs → Microsoft → Windows → WMI-Activity → Trace → right-click Enable Log.

    After the shutdown, look for Event ID 11 in that log. Use ClientProcessId and ClientMachine (can reveal remote initiators)

    3. Run Process Monitor with an auto-stop trigger

    Trigger on System / User32 / 1074, then stop Procmon:

    "C:\WMI\procmon.exe" /Terminate

    4. Inspect processes running as DomainUser

    Run via powerShell:

    # List everything running in the user's session

    Get-CimInstance Win32_Process |

    Where-Object { (Invoke-CimMethod -InputObject $ -MethodName GetOwner).User -eq 'DomainUser' } |_

    Select-Object ProcessId, Name, CommandLine, CreationDate |

    Sort-Object CreationDate

    Compare with a healthy machine. Differences often include startup scripts / HKCU\Run, kiosk tools, RMM agents, idle-timeout utilities and custom apps calling shutdown APIs

    5. Baseline recent 1074 events via Powershell

    Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} -MaxEvents 20 |

    Select-Object TimeCreated,

    @{n='Process';e={$.Properties[0].Value}},_

    @{n='User';e={$.Properties[6].Value}},_

    @{n='ReasonCode';e={'0x{0:X}' -f $.Properties[3].Value}},_

    @{n='Type';e={$.Properties[4].Value}} |_

    Format-Table -AutoSize

    If consistently RuntimeBroker.exe + Power off, this confirms an in-session API call, not hardware or OS failure.

    Was this answer helpful?

    0 comments
  3. David 0 Reputation points
    2026-05-29T10:06:13.2033333+00:00

    I have just been informed, that we do have one system, that consistently shuts down daily. There is still no pattern for the time of day, but at least we now have a test subject where we won't have to wait too long to see results.
    I also got the Event wrong, though on most systems, that i checked we did have the previously mentioned event ause the shutdown.

    It reads:
    The process C:\Windows\System32\RuntimeBroker.exe (Computer) has initiated the power off of computer "Computername" on behalf of user "Domain\DomainUser" for the following reason: "Other (Unplanned)"
    Reason Code: "0x0"
    Shutdown Type: "power off "
    Comment: ""

    The problem however persists.

    Was this answer helpful?

    0 comments
  4. Daphne Huynh (WICLOUD CORPORATION) 660 Reputation points Microsoft External Staff Moderator
    2026-05-29T03:12:50.99+00:00

    Welcome to Microsoft Q&A Forum! 

    Your issue is not a hardware crash but controlled, programmatic shutdowns triggered by shutdown.exe with Event ID 1074 and reason code 0x800000ff. This strongly suggests SCCM deployments, scheduled tasks, WMI calls, or third‑party agents are initiating shutdowns, and the next step is to trace which process or service is calling the shutdown API.

    I would like to share some useful information about the event ID 1074 and other concern.

    • Controlled shutdown/restart: Logged when a process, script, service, or user explicitly requests shutdown.
    • Reason code 0x800000ff: “No title for this reason could be found.” Indicates a programmatic trigger without a mapped reason string.
    • SYSTEM vs DOMAIN\User initiators: Both are consistent with automated tools (SCCM, WMI, scheduled tasks) rather than random crashes.

    Reference: Identify the cause of unexpected WMI shutdowns - Windows Server | Microsoft Learn

    Based on your findings and enterprise patterns, the most probable triggers are:

    • SCCM / Configuration Manager: Reboots triggered by software updates or task sequences. Check: C:\Windows\CCM\Logs\RebootCoordinator.log for entries like requested from or scheduled reboot.
    • Scheduled Tasks or automation: Hidden/system tasks or GPO‑deployed jobs can run under SYSTEM even if disabled visibly.
    • WMI shutdowns: Scripts or management tools using Win32Shutdown silently trigger shutdowns. Microsoft documents enabling WMI Activity tracing to capture PID and user responsible.
    • Third‑party agents: Antivirus, monitoring, or legacy software may programmatically call shutdown APIs.
    • Custom applications: Even if logs show nothing, background components can conditionally trigger shutdowns.

    Hence, I would like to share the following recommended solutions that may you. 

    1. Filter Event Viewer

    • Look for Event IDs 1074, 13, 6009 (planned shutdowns).
    • Absence of 41/6008 confirms no crash/power loss.

    2. Trace initiator

    • Compare SYSTEM vs DOMAIN\User in Event 1074
    • Review process ID and timestamps

    3. Check SCCM reboot triggers

    Review: _C:\Windows\CCM\Logs\RebootCoordinator._log. And look for “requested from”, “scheduled reboot”, “reboot request succeeded”. This is one of the most reliable sources in SCCM environments

    4. Enable deeper tracing

    • Enable: Applications and Services Logs → Microsoft → Windows → WMI-Activity → Trace
    • Capture WMI shutdown requests and process ID responsible

    This is required when shutdown is triggered programmatically

    5. Use Process Monitor (ProcMon)

    • Filter for process name (shutdown.exe)
    • Capture during reproduction window

    It helps identify parent process calling shutdown.exe

    6. Validate scheduled tasks

    • Check Task Scheduler, hidden/system tasks, GPO-deployed tasks
    • Run: schtasks /query /fo LIST /v

    7. Compare affected vs unaffected machines

    Review installed software, services, SCCM deployments, Task Scheduler entries

    I hope this information is helpful and thank you for choosing Microsoft Q&A to raise your concern. 

    Was this answer helpful?

    0 comments

  5. AI answer

    2026-05-28T14:13:17.72+00:00

    Event ID 1074 with source User32 and process shutdown.exe indicates a controlled shutdown request, not a crash. The key is to identify what is calling shutdown.exe with reason code 0x800000ff on those clients.

    Use the following approach to trace and attribute the shutdowns without reimaging:

    1. Classify the reboot type
      • On affected clients, open Event Viewer → Windows Logs → System.
      • Filter for Event IDs 13, 41, 1074, 6008, 6009 with the relevant sources:
        • 1074 (User32): who/what initiated the shutdown.
        • 13 (Kernel-General): normal OS shutdown.
        • 41 (Kernel-Power) and 6008 (EventLog): unexpected/dirty shutdowns.
      • If the pattern is 1074 → 13 → 6009 without 41/6008, these are normal, requested shutdowns, not power loss or kernel failures.
    2. Inspect Event ID 1074 details
      • For each shutdown, open the 1074 event and review:
        • Process Name (for example, C:\Windows\System32\shutdown.exe).
        • User (SYSTEM or domain user).
        • Reason Code (0x800000ff or others) and Shutdown Type.
      • Use the reason code references to decode the meaning:
        • See Shutdown Reasons and System Shutdown Reason Codes for how 0x800000ff and other codes map to categories.
      • Compare events where the user is SYSTEM vs. domain users to see whether a service, scheduled task, or WMI call is involved.
    3. Check for WMI-initiated shutdowns
      • Because WMI can call Win32Shutdown on Win32_OperatingSystem, a script or management tool may be issuing shutdowns via WMI.
      • On an affected client, enable WMI Activity tracing:
        • Event Viewer → Applications and Services Logs → Microsoft → Windows → WMI-Activity → Trace.
        • From the View menu, enable Show Analytic and Debug Logs, then enable the Trace log.
      • This trace records the PID and user for WMI shutdown requests.
    4. Set up an automated capture when shutdown is requested
      • On a test client that exhibits the issue, configure a Task Scheduler job to trigger on Event ID 1074 and collect more data:
        1. Create a folder such as C:\WMI and place a StopTrace.bat script there (as in the documented procedure) to stop Procmon and save WMI traces.
        2. In Task Scheduler:
          • Create a new task.
          • On Triggers:
            • New → Begin the task: On an event.
            • Log: System.
            • Source: User32.
            • Event ID: 1074.
          • On Actions:
            • New → Start a program → point to C:\WMI\StopTrace.bat.
        3. Before reproducing, start the capture by running StartTrace.bat from an elevated Command Prompt in C:\WMI.
      • When the unexpected shutdown occurs, the task will run StopTrace.bat, stopping Process Monitor and saving the WMI trace.
    5. Analyze the traces after a shutdown
      • After the machine restarts:
        1. Open C:\WMI\WMI-ActivityLog.evtx in Event Viewer.
        2. Use Filter Current Log to narrow down to the time of the shutdown.
        3. Identify the PID and user associated with any Win32Shutdown calls.
      • Correlate the PID with the Process Monitor trace to see which executable (for example, your custom app, a management agent, or another tool) issued the shutdown.
    6. Check for SEL/BMC reason code anomalies (if applicable)
      • If these systems are servers with a BMC, be aware that some user-initiated shutdowns can write incorrect reason codes (for example, 0x500ff) to the System Event Log (SEL) even when a different reason was chosen.
      • As a workaround, use shutdown.exe with explicit reason codes (for example, shutdown.exe /r /d P:4:2) in any scripts so that SEL and event logs carry consistent, decodable reasons.
    7. Distinguish OS vs. external causes
      • Documentation notes that most unexpected shutdowns are caused by components outside the OS (power, hardware, firmware, or external management tools).
      • Once the initiating process is identified via WMI/Procmon tracing and Event ID 1074, focus on that component:
        • If it is the custom application, instrument or update it.
        • If it is a management agent, review its policies.
        • If it is a scheduled task, disable or adjust it.

    By combining Event ID 1074 analysis, WMI Activity tracing, and a triggered capture, the exact process and mechanism issuing shutdown.exe with code 0x800000ff can be identified without reimaging the affected clients.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.