What does BSOD 239 (CRITICAL_PROCESS_DIED) mean?

 
Previous Next
UNMOUNTABLE_BOOT_VOLUME STORAGE_MINIPORT_ERROR

CRITICAL_PROCESS_DIED

The CRITICAL_PROCESS_DIED bug check has a value of 0x000000EF. This indicates that a critical system process died. A critical process is one that forces the system to bug check if it terminates. This can happen when the state of the process is corrupted or otherwise is damaged. When this happens, as these processes are critical to the operation of Windows, a system bug check occurs as the operating system integrity is in question.

Built in Windows critical system services include csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe, and winlogon.exe.

A developer can also create a service and set its recovery option to Restart the Computer, for more information see Set up Recovery Actions to Take Place When a Service Fails.

Important

CRITICAL_PROCESS_DIED Parameters

Parameter Description

1

The process object

2

If this is 0, a process died. If this is 1, a thread died.

3

Reserved

4

Reserved

Resolution for CRITICAL_PROCESS_DIED

Determining the cause of this issues typically requires the use of the debugger to gather additional information. For CRITICAL_PROCESS_DIED, multiple dump files should be examined to see if this stop code has similar characteristics, such as the code that is running when the stop code appears.

For more information, see Crash dump analysis using the Windows debuggers used to investigate CRITICAL_PROCESS_DIED (WinDbg), Using the !analyze Extension and !analyze.

In many cases a user dump is also created before the system bugchecks. In general, when a user dump is available, it should be examined first to root cause the issue. This is because there are limitations to debugging user mode code from the kernel dump, including paged out/missing data. For more information see, User-Mode Dump Files.

Consider using the event log to see if there are errors that occur leading up to this stop code. If there are, these errors can be used to examine specific services or other code to investigate.

Once information about the code in question is available, set a breakpoint in the related code before this code is executed and single step forward through the code looking at the values of critical variables that are used to control the code flow. For CRITICAL_PROCESS_DIED, carefully examine this area of your code to look for false assumptions or other mistakes.

Use the second parameter of the bug check to determine if a dying process or thread caused the bug check.

If it is a process, use the !process command to display information on the process before and after the point of failure to look for abnormal behavior. The Process explorer utility can used to gather general information about which process are running and parent child relationships.

If it is a thread, consider using the !thread command to display information about the thread. For information about threads in kernel mode, see Changing Contexts.

For general information on threads and process as well as additional specifics on Windows protected, critical code such as wininit and csrss, see Windows Internals by Pavel Yosifovich, Mark E. Russinovich, David A. Solomon, and Alex Ionescu.

General Troubleshooting Tips for CRITICAL_PROCESS_DIED

If you are not able to work with the debugger, these general troubleshooting tips may be helpful.

  • For CRITICAL_PROCESS_DIED, if you recently added hardware to the system, try removing or replacing it. For CRITICAL_PROCESS_DIED, or check with the manufacturer to see if any patches are available.

  • For CRITICAL_PROCESS_DIED, if new device drivers or system services have been added recently, try removing or updating them. For CRITICAL_PROCESS_DIED, try to determine what changed in the system that caused the new bug check code to appear.

  • For CRITICAL_PROCESS_DIED, check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. For more information, see Open Event Viewer. For CRITICAL_PROCESS_DIED, look for critical errors in the system log that occurred in the same time window as the blue screen.

  • Check with the manufacturer to see if an updated system BIOS or firmware is available.

  • For CRITICAL_PROCESS_DIED, you can try running the hardware diagnostics supplied by the system manufacturer.

  • For CRITICAL_PROCESS_DIED, confirm that any new hardware that is installed is compatible with the installed version of Windows. For example, you can get information about hardware required for a system affected by CRITICAL_PROCESS_DIED at Windows 10 Specifications.

  • Run a virus detection program. For CRITICAL_PROCESS_DIED, viruses can infect all types of hard disks formatted for Windows, and resulting disk corruption can generate system bug check codes. For CRITICAL_PROCESS_DIED, make sure the virus detection program checks the Master Boot Record for infections.

  • For CRITICAL_PROCESS_DIED, use the System File Checker tool while investigating CRITICAL_PROCESS_DIED to repair missing or corrupted system files. For CRITICAL_PROCESS_DIED, the System File Checker is a utility in Windows that allows users to scan for corruptions in Windows system files and restore corrupted files. For CRITICAL_PROCESS_DIED, use the following command to run the System File Checker tool (SFC.exe).

    REM CRITICAL_PROCESS_DIED diagnostic command.
SFC /scannow

    For more information, see Use the System File Checker tool to repair missing or corrupted system files.

  • For CRITICAL_PROCESS_DIED, Look in Device Manager to see if any devices are marked with the exclamation point (!). For CRITICAL_PROCESS_DIED, review the events log displayed in driver properties for any faulting driver. Try updating the related driver.

See also for CRITICAL_PROCESS_DIED

Crash dump analysis using the Windows debuggers (WinDbg)

Analyzing a Kernel-Mode Dump File with WinDbg

Looking for a different code? Search another status or error code.