⚠ CrashDecoder

0x000000F4 CRITICAL_OBJECT_TERMINATION

Windows depends absolutely on a handful of processes and threads. When one of them exits - cleanly, crashed, or killed - there is nothing left to fall back to, so the system stops. What makes this code more tractable than it looks is that the parameters name the process directly and include a pointer to a plain-text explanation.

Updated 2026-07-28Stop error - frequently a boot loopAlso written: 0xF4, CRITICAL OBJECT TERMINATION, critical_object_termination

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: CRITICAL_OBJECT_TERMINATION

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x000000f4 (0x0000000000000003, 0xffffa50c1d2e4080, 0xffffa50c1d2e4360, 0xfffff8036c2b1a40).

What the error actually means

A small set of user-mode processes hold the system together. csrss.exe handles console and window management for the kernel. wininit.exe and winlogon.exe run session startup and logon. services.exe manages every service. lsass.exe is the security subsystem. smss.exe is the session manager.

Windows marks these as critical. Microsoft's description is direct: several processes and threads are necessary for the operation of the system, and when they are terminated for any reason the system can no longer function.

There is no degraded mode to fall back to - a Windows without csrss.exe is not a reduced Windows, it is not Windows. So the kernel stops and records which object went away.

Reading the parameters

Better than average. Parameter 3 names the process, and parameter 4 points at an actual sentence explaining what happened.

ParameterWhat it holds
1The terminating object type. 0x3 means a process terminated; 0x6 means a thread did. Worth noting - a dead thread inside an otherwise healthy process is a different situation from the whole process exiting.
2The terminating object itself. A pointer, useful only in a debugger.
3The process image file name. This is your diagnosis - it names which process died, and that determines everything about where to look next.
4A pointer to an ASCII string containing an explanatory message. In WinDbg, da <address> displays it as readable text. Unusually helpful for a bugcheck parameter, and almost nobody reads it.

What actually triggers it

Which cause is likely depends heavily on which process died, so treat this as a starting distribution.

CauseHow oftenDetail
Corrupt system filesCommonA damaged system binary, or a component store in an inconsistent state, leaves a critical process unable to start or unable to continue. Unlike most stop codes, this is genuinely a leading cause here rather than a reflex recommendation.
Failing storageCommonIf the drive cannot reliably return the files these processes depend on, they die. A drive developing bad sectors in the wrong region produces this repeatedly and worsens quickly.
A bad or interrupted updateOccasionalAn update that fails partway leaves mismatched system components. Crashes starting immediately after an update, especially after a power loss during one, point here.
Third-party security softwareOccasionalAnti-virus products interact directly with lsass.exe and services.exe. A version mismatch after a Windows update can terminate them.
MalwareOccasionalMore relevant here than on most codes, because some malware specifically targets or injects into these processes - and badly written malware simply crashes them.
Failing RAMRarePossible, though you would normally expect other stop codes alongside it.

Narrowing it down

Get the process name first. Everything else follows from it.

Read parameters 3 and 4 from the dump

Open the newest minidump in WinDbg, run !analyze -v, then read PROCESS_NAME. To see the explanatory message, take the address from parameter 4 and run:

da <address from Arg4>

That prints the ASCII string Windows attached to the bugcheck.

What it tells you

csrss.exe is the broadest and least specific. lsass.exe points toward security software, credential store corruption or disk problems in the security hives. services.exe suggests a service or its driver. The name narrows a wide field considerably.

Note whether it was a process or a thread

Parameter 1 distinguishes them: 0x3 for a process, 0x6 for a thread.

What it tells you

A whole process exiting usually means it hit a fatal error or was killed. A critical thread dying inside a surviving process more often points at a driver or a fault in a specific code path rather than at the process as a whole.

Check the drive early

Given how often storage is behind this, do it before spending an evening on software. Read SMART data with CrystalDiskInfo from a working Windows, or run chkdsk from the recovery environment - confirming drive letters with diskpart and list volume first, since they are usually not what you expect there.

What it tells you

Reallocated or pending sectors, or degraded SSD health, makes storage the answer and makes every software repair below temporary.

Establish whether you can boot at all

If Windows starts and crashes occasionally you have full access. If it loops, interrupt the boot three times to reach the recovery environment.

What it tells you

Safe Mode working but normal boot failing implicates a driver or startup service rather than core corruption - the critical processes clearly can run when the environment is minimal.

Fixes, cheapest first

If you are looping, all of this runs from the recovery environment. Reach it by interrupting boot three times.

  1. Repair system files

    Effort: 45 minutes · Risk: Low

    From a working Windows, in an administrator terminal:

    sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

    From recovery, use the offline form - and confirm the drive letters first with diskpart and list volume:

    sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
    Watch out

    In recovery the Windows installation is often on D: while the recovery image is on X:. Running these against the wrong letter does nothing and wastes a lot of time.

  2. Check and repair the disk

    Effort: 30 minutes to hours · Risk: Low

    Run chkdsk C: /f /r against the Windows volume. The /r surface scan takes considerably longer but is the point of the exercise on a drive you suspect.

    Watch out

    On a drive that is genuinely failing, a full surface scan can accelerate the failure. Image the drive first if the data matters.

  3. Uninstall the most recent update

    Effort: 20 minutes · Risk: Low

    If this started after an update, remove it. From recovery: Troubleshoot, Advanced options, Uninstall Updates - which offers the latest quality update and the latest feature update separately.

  4. Strip back security software from Safe Mode

    Effort: 30 minutes · Risk: Low

    If Safe Mode works, use it to remove third-party anti-virus with the vendor's dedicated removal tool, along with VPN clients and anything else installing kernel drivers. This is the fastest route when lsass.exe or services.exe is the process that died.

  5. Scan for malware offline

    Effort: 1 hour · Risk: Low

    Because this stop code involves processes malware specifically targets, an offline scan carries more weight here than usual. Microsoft Defender Offline runs before Windows loads and can see what a normal scan cannot - from Windows Security, choose Virus and threat protection, Scan options, Microsoft Defender Offline scan.

  6. Repair install without losing files

    Effort: 1-2 hours · Risk: Medium

    An in-place upgrade replaces every system file while keeping applications, settings and data. It resolves corruption that sfc and DISM cannot.

    1. Build installation media with the Media Creation Tool, or mount the ISO from a working Windows.
    2. Run setup.exe from within Windows, not by booting from the media.
    3. Choose to keep personal files and apps.
    4. Let it finish without interruption.
    Watch out

    Needs a bootable Windows to start from - Safe Mode may be enough. Back up first.

When it is the hardware, not Windows

Signals that the storage device is the underlying problem:

The last one settles it. Repairing files on a failing drive writes to a surface that cannot hold them reliably - the repair appears to work and then decays over days. If a fresh installation reproduces the problem on the same disk, replace the disk rather than the operating system, and copy your data off while it still reads.

Frequently asked

How is this different from CRITICAL_PROCESS_DIED?

They describe the same category of failure from slightly different angles. 0xEF CRITICAL_PROCESS_DIED fires specifically when a process marked critical terminates. 0xF4 CRITICAL_OBJECT_TERMINATION is the broader form and covers a critical thread as well as a process - parameter 1 tells you which. For troubleshooting purposes they are interchangeable: find out what died, then check system files and the drive.

What is the explanatory message in parameter 4?

A plain ASCII string Windows attaches describing what happened. In WinDbg, da followed by the parameter 4 address prints it. It is often terse, but it occasionally states the condition outright in a way the rest of the dump does not - and it costs one command to check. Almost nobody looks at it, which is a shame given it is the only bugcheck parameter that is literally a sentence.

It says csrss.exe. Does that narrow anything?

Less than you would like. csrss.exe is involved in a great deal of ordinary activity, so it is the process most likely to be caught up in a problem originating elsewhere. Treat it as confirming the category rather than identifying the cause, and lean on the drive check and system file repair. A more specific name like lsass.exe is far more directive.

Can a third-party program kill a critical process?

Not easily, and Windows protects against it - attempting to terminate a critical process is what produces this bugcheck rather than a successful kill. But security software, anti-cheat and system utilities operate close enough to these processes to destabilise them, and an injected DLL that crashes will take its host down. That is why removing third-party kernel-level software is a reasonable step when lsass.exe or services.exe is involved.