Commonly BSOD crashes only happen within kernel mode because only in kernel mode problems can occur that are fatal to Windows. While that is a pretty strict rule, like with many other rules, there is an exception to this rule. The 0xEF or CRITICAL PROCESS DIED bugcheck is the exception to the rule. For us to understand why the 0xEF is the exception, we need to understand a part of the boot process.
In the boot process, just before the login screen is shown, Smss.exe, Wininit.exe, and Csrss.exe are working. Smss.exe (Session Manager Sub System) is a native application, which means that it does not use the APIs that Windows provides. Smss is also considered as a trusted part of Windows which allows Smss.exe to perform a few actions that few others can also do. This makes Smss a special process and is what distinguishes Smss from other user-mode processes.
Smss doesn't use the systems of Windows, because one of the first tasks Smss has is initializing those systems. The very first task Smss does is mark itself as a critical process and mark the main thread as a critical thread. That means that if, for any reason, the critical thread or the process itself exits, Windows crashes. This happens because Windows simply cannot run without processes that are marked as critical. A few other tasks Smss has is initializing Wininit and Csrss. Smss initializes session 0. Whilst the command for initializing session 0 is executed the same command to initialize session 0 is also launching Wininit process. Csrss (Client/Server Run-time Sub System) is started with the call SmpStartCsr that is executed a few tasks later. Csrss, in turn, loads win32k.sys which uses the video driver to change the resolution so you won't be greeted with a small resolution.
After the initialization session of Smss is performed, Wininit will continue to run, also marks itself as critical and some tasks later lets Winlogon take over. Meanwhile, Csrss has also been marked as critical.
Smss, Csrss, and Wininit are responsible for loading various Windows internal systems, the desktop so you can work, the login screen, and a lot more.
If any critical process or critical thread exits for any reason then Windows has no choice but to stop itself from running and thus in kernel mode it will force a BSOD with reason CRITICAL_PROCESS_DIED. While a BSOD can only be created from kernel mode, the reason behind a BSOD is not limited to kernel mode.
This is the general picture behind a critical process/thread. Not every process that is a critical process is mentioned.
While we now understand the reason behind the 0xEF crash, debugging is not made any easier. The 0xEF crash starts in user mode which brings with it a drawback. We are used to looking into kernel mode operations and have the resources (symbols) to do just that with thanks to Microsoft. Looking into user mode operations requires the largest dump that Windows can possibly make because a normal kernel memory dump (not a minidump) contains all kernel-mode data but nothing else. A complete memory dump contains both kernel-mode and user-mode data but is incredibly large, these days it can be anywhere from 8GB to 32GB, basically the size of RAM that's installed. That is however not the main drawback, the main drawback is that if we want to be able to look properly in all the data that's present, we need resources that are mostly private. Those symbols are symbols that allow Windbg to recognize code from third-party programs. Many third-party vendors get paid for writing code and there's no way they'll provide the resources to us just so we can look at a complete memory dump for a 0xEF crash that happens once in a while. We can look into user-mode data though, but since we do not have the right resources we are simply limited to what we can do. That is why debugging a 0xEF is not made any easier after understanding the reason behind the cause.
Speaking of causes, if you have looked at Carrona's BSOD Index you can notice there's barely any information available about the 0xEF crash. As such, we cannot really depend on Carrona's website for this instance we have to get this information in another way. One way is through experience. Fortunately, after a few years, it is possible to provide a shortlist of the most probable causes for this crash. From what I've seen this particular crash is mostly caused by issues with the drive or the RAM. The reason for the crash is not limited to these parts though, it could also be caused by the motherboard or PSU, for example, but it is not realistic to extend the most probable causes to more than the drive or the RAM. Theoretically, the 0xEF could be caused by some other part but the RAM or drive, in practice that rarely happens, if ever. While talking about causes, malware should not be forgotten. Although over the past couple of years malware hasn't been what it used to be, sophisticated malware can be a reason for this particular crash. Since many malware authors have changed their direction it is very unlikely to see malware these days that could potentially cause the 0xEF crash but isn't blocked by current antivirus solutions before it can.
In the boot process, just before the login screen is shown, Smss.exe, Wininit.exe, and Csrss.exe are working. Smss.exe (Session Manager Sub System) is a native application, which means that it does not use the APIs that Windows provides. Smss is also considered as a trusted part of Windows which allows Smss.exe to perform a few actions that few others can also do. This makes Smss a special process and is what distinguishes Smss from other user-mode processes.
Smss doesn't use the systems of Windows, because one of the first tasks Smss has is initializing those systems. The very first task Smss does is mark itself as a critical process and mark the main thread as a critical thread. That means that if, for any reason, the critical thread or the process itself exits, Windows crashes. This happens because Windows simply cannot run without processes that are marked as critical. A few other tasks Smss has is initializing Wininit and Csrss. Smss initializes session 0. Whilst the command for initializing session 0 is executed the same command to initialize session 0 is also launching Wininit process. Csrss (Client/Server Run-time Sub System) is started with the call SmpStartCsr that is executed a few tasks later. Csrss, in turn, loads win32k.sys which uses the video driver to change the resolution so you won't be greeted with a small resolution.
After the initialization session of Smss is performed, Wininit will continue to run, also marks itself as critical and some tasks later lets Winlogon take over. Meanwhile, Csrss has also been marked as critical.
Smss, Csrss, and Wininit are responsible for loading various Windows internal systems, the desktop so you can work, the login screen, and a lot more.
If any critical process or critical thread exits for any reason then Windows has no choice but to stop itself from running and thus in kernel mode it will force a BSOD with reason CRITICAL_PROCESS_DIED. While a BSOD can only be created from kernel mode, the reason behind a BSOD is not limited to kernel mode.
This is the general picture behind a critical process/thread. Not every process that is a critical process is mentioned.
While we now understand the reason behind the 0xEF crash, debugging is not made any easier. The 0xEF crash starts in user mode which brings with it a drawback. We are used to looking into kernel mode operations and have the resources (symbols) to do just that with thanks to Microsoft. Looking into user mode operations requires the largest dump that Windows can possibly make because a normal kernel memory dump (not a minidump) contains all kernel-mode data but nothing else. A complete memory dump contains both kernel-mode and user-mode data but is incredibly large, these days it can be anywhere from 8GB to 32GB, basically the size of RAM that's installed. That is however not the main drawback, the main drawback is that if we want to be able to look properly in all the data that's present, we need resources that are mostly private. Those symbols are symbols that allow Windbg to recognize code from third-party programs. Many third-party vendors get paid for writing code and there's no way they'll provide the resources to us just so we can look at a complete memory dump for a 0xEF crash that happens once in a while. We can look into user-mode data though, but since we do not have the right resources we are simply limited to what we can do. That is why debugging a 0xEF is not made any easier after understanding the reason behind the cause.
Speaking of causes, if you have looked at Carrona's BSOD Index you can notice there's barely any information available about the 0xEF crash. As such, we cannot really depend on Carrona's website for this instance we have to get this information in another way. One way is through experience. Fortunately, after a few years, it is possible to provide a shortlist of the most probable causes for this crash. From what I've seen this particular crash is mostly caused by issues with the drive or the RAM. The reason for the crash is not limited to these parts though, it could also be caused by the motherboard or PSU, for example, but it is not realistic to extend the most probable causes to more than the drive or the RAM. Theoretically, the 0xEF could be caused by some other part but the RAM or drive, in practice that rarely happens, if ever. While talking about causes, malware should not be forgotten. Although over the past couple of years malware hasn't been what it used to be, sophisticated malware can be a reason for this particular crash. Since many malware authors have changed their direction it is very unlikely to see malware these days that could potentially cause the 0xEF crash but isn't blocked by current antivirus solutions before it can.
Last edited:
