Site icon EfmSoft

What is 239 (0x000000EF) bug check

 
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

This topic is for programmers. If you are a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.

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

Determining the cause of this issues typically requires the use of the debugger to gather additional information. 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 (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. 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

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

See also

Crash dump analysis using the Windows debuggers (WinDbg)

Analyzing a Kernel-Mode Dump File with WinDbg

Exit mobile version