Windows Stop Code 0x000000E2 – MANUALLY_INITIATED_CRASH: Causes and Troubleshooting

Quick Answer

Windows Stop Code 0x000000E2 – MANUALLY_INITIATED_CRASH indicates that a system crash was deliberately initiated through a keyboard shortcut or a kernel debugger. Windows generates this bug check when a user or diagnostic tool intentionally requests a crash dump.

This error does not, by itself, indicate a faulty RAM module, hard drive, driver, or other hardware component. If it appears unexpectedly, investigate whether someone accidentally activated the configured keyboard shortcut or whether a debugging tool initiated the crash.

Bug Check Code: 0x000000E2
Bug Check Name: MANUALLY_INITIATED_CRASH
Bug Check Parameters: None

What Is MANUALLY_INITIATED_CRASH?

MANUALLY_INITIATED_CRASH is a Windows stop error with the bug check value 0x000000E2. It occurs when Windows receives an instruction to deliberately stop the operating system and generate a diagnostic crash dump.

This functionality is primarily intended for IT professionals, developers, and system administrators who need to capture the system's memory state for troubleshooting. For example, if a computer becomes unresponsive, a technician may deliberately trigger a crash to collect diagnostic information for later analysis.

Microsoft identifies two common ways to initiate this crash:

• Keyboard shortcut: A configured keyboard combination triggers a manual system crash.
• Kernel debugger: A debugging tool such as WinDbg or KD issues a command to force a system crash.

Therefore, 0xE2 is different from stop codes that directly report an unexpected operating-system or hardware condition. The bug check confirms that a manual crash request was issued; it does not explain why the request was made.

Common Causes of Error 0x000000E2

The following situations can result in the MANUALLY_INITIATED_CRASH stop code:

Possible cause	Explanation
Accidental keyboard shortcut	A configured crash shortcut may have been pressed unintentionally.
CrashOnCtrlScroll enabled	The Windows registry contains a setting that allows a keyboard combination to initiate a crash.
Kernel debugging activity	A technician or developer may have used the .crash command in WinDbg or KD.
IT support troubleshooting	A support technician may have deliberately generated a memory dump while investigating a frozen computer.
Diagnostic or driver testing	A developer may have intentionally triggered a crash to test debugging or crash-dump collection.
Remote debugging session	An administrator working with a kernel debugging session may have requested a crash on the target computer.

These are possible triggering situations. The actual circumstances should be established from the system's configuration, event logs, and the activities performed before the crash.

Symptoms of MANUALLY_INITIATED_CRASH

When Windows encounters this bug check, you may notice one or more of the following symptoms:

• A blue screen appears with the stop code 0x000000E2.
• The error name MANUALLY_INITIATED_CRASH is displayed.
• The computer immediately stops responding to normal user input.
• Windows attempts to collect crash dump information, if dump collection is configured and available.
• The computer may restart automatically after the dump collection process.
• Unsaved documents and other open work may be lost.

The appearance of these symptoms does not necessarily mean that Windows is damaged. A manually initiated crash is designed to stop the system.

How to Fix Windows Stop Code 0x000000E2

The appropriate troubleshooting method depends on whether the crash was intentionally generated or occurred unexpectedly. Follow the steps below to identify the triggering mechanism.

1. Check Whether Someone Deliberately Initiated the Crash

Start by investigating the activities performed immediately before the blue screen appeared.

1. Ask whether an IT technician was troubleshooting a frozen or unresponsive computer.
2. Check whether anyone was using WinDbg, KD, or another kernel debugging tool.
3. Determine whether a keyboard crash shortcut was being tested.
4. Check whether the computer was undergoing driver development, system testing, or diagnostic procedures.
5. Review the Windows event logs to establish the approximate time of the crash.

If a technician deliberately generated the crash to collect a memory dump, the stop code may be the expected result of that operation. In that situation, investigate the original system problem using the collected dump rather than treating 0xE2 itself as the underlying fault.

2. Understand the Keyboard Shortcut That Triggers 0xE2

Windows supports a keyboard-initiated crash feature for supported keyboard drivers. When the feature is enabled, the following keyboard combination can deliberately stop Windows:

1. Press and hold the rightmost Ctrl key.
2. While holding it, press the Scroll Lock key twice.
3. Windows initiates bug check 0xE2.

This shortcut is not necessarily enabled by default. It requires the appropriate registry configuration and a restart before it becomes active.

Some laptops use different keyboard drivers for their built-in and external keyboards. As a result, the relevant configuration may exist under more than one keyboard driver registry location.

Important: Do not test this shortcut on a working computer. It deliberately stops Windows and can cause the loss of unsaved work.

3. Check the CrashOnCtrlScroll Registry Setting

The keyboard-initiated crash feature is controlled by a registry value named CrashOnCtrlScroll. Check the relevant registry locations to determine whether the feature is enabled.

USB keyboard registry location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

PS/2 keyboard registry location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

Hyper-V keyboard registry location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hyperkbd\Parameters

To check the USB keyboard configuration, open Command Prompt and execute:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters" /v CrashOnCtrlScroll

To check the PS/2 keyboard configuration, execute:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters" /v CrashOnCtrlScroll

To check the Hyper-V keyboard configuration, execute:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\hyperkbd\Parameters" /v CrashOnCtrlScroll

These commands only read the registry and do not change its settings.

If the output contains CrashOnCtrlScroll with a REG_DWORD value of 0x1, the keyboard-initiated crash feature is enabled for that driver.

If Windows reports that the specified registry value cannot be found, the value is not configured at that location. This does not rule out a configuration under another keyboard driver.

4. Disable the Keyboard-Initiated Crash Feature

If keyboard-initiated crash functionality is not required, you can remove the CrashOnCtrlScroll registry value from the relevant keyboard driver configuration.

Before making changes:

• Confirm that the feature is not required by your IT support or debugging team.
• Create a backup of the relevant registry key.
• Use an administrator account to perform the operation.
• Remove only the specific CrashOnCtrlScroll value, not the entire registry key.

For a USB keyboard:

reg delete "HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters" /v CrashOnCtrlScroll /f

For a PS/2 keyboard:

reg delete "HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters" /v CrashOnCtrlScroll /f

For a Hyper-V keyboard:

reg delete "HKLM\SYSTEM\CurrentControlSet\Services\hyperkbd\Parameters" /v CrashOnCtrlScroll /f

Run only the command corresponding to the registry location you intend to change. If multiple keyboard drivers have the value configured, review each one separately.

Restart Windows after making the changes. Removing this value disables the corresponding keyboard-triggered crash configuration; it does not repair an unrelated system problem.

5. Review Windows Event Viewer Logs

Event Viewer can help establish when the system stopped and whether Windows recorded a bug check or unexpected restart.

1. Press Windows + R.
2. Type eventvwr.msc.
3. Press Enter to open Event Viewer.
4. Expand Windows Logs.
5. Select System.
6. Look for events recorded around the time of the blue screen.

Pay attention to these events:

Event	What it indicates
BugCheck	May contain the bug check code and information about the recorded crash.
Kernel-Power, Event ID 41	Indicates that Windows restarted without a clean shutdown. It does not independently identify the original cause.
EventLog, Event ID 6008	Records that the previous shutdown was unexpected.

Compare the event timestamps with the time when the keyboard shortcut or debugging operation may have been used. Do not interpret Event ID 41 or 6008 alone as proof of a hardware failure.

6. Locate and Preserve the Memory Dump File

When Windows is configured to collect crash dumps, it may create a memory dump file after the bug check. These files can help technicians investigate the system state at the time of the crash.

Check the following common locations:

• C:\Windows\MEMORY.DMP – The default location commonly used for a configured complete or kernel memory dump.
• C:\Windows\Minidump\ – A directory that may contain small memory dump files.

To open the Windows system directory:

1. Press Windows + R.
2. Enter %SystemRoot%.
3. Press Enter.
4. Look for MEMORY.DMP or the Minidump folder.

If the files are present, preserve a copy before performing further troubleshooting. Avoid deleting dump files until the investigation is complete.

If no dump file is available, check the configured crash dump settings and available disk space. A dump is not guaranteed to be created for every crash.

7. Analyze the Dump File Using WinDbg

IT support technicians and system administrators can use WinDbg to examine a Windows memory dump.

1. Install WinDbg using Microsoft's official documentation.
2. Open WinDbg.
3. Select the option to open a dump file.
4. Choose the relevant MEMORY.DMP or minidump file.
5. Allow the debugger to load the required symbols.
6. Enter the following command in the debugger command window:

!analyze -v

The command displays detailed bug check analysis and the diagnostic information available in the dump.

For bug check 0xE2, Microsoft specifies that there are no bug check parameters. Consequently, the stop code itself does not identify a particular driver, device, or hardware component as the cause.

If the manual crash was generated because the computer had previously frozen, the technician should examine the broader system state and correlate the debugger findings with other available diagnostic evidence. A driver appearing in the analysis is not automatically proof that it caused the original freeze.

8. Understand the WinDbg .crash Command

During an active kernel-mode debugging session, WinDbg or KD can deliberately force a crash on the target computer.

The debugger command is:

.crash

This command causes the target system to call the Windows bug check mechanism and issue bug check 0xE2. If the target computer does not crash immediately, Microsoft documents following the command with:

g

Unless crash dumps have been disabled, Windows writes a crash dump file. After the dump has been written, the kernel debugger on the host computer is notified and can be used to continue debugging the target.

Warning: The .crash command deliberately stops the target operating system. It is intended for controlled kernel debugging and must not be used as an ordinary troubleshooting command on a production computer.

Important Limitations of Keyboard-Initiated Crash Dumps

The keyboard crash shortcut has specific configuration and operational requirements.

• The relevant keyboard driver must support the feature.
• The CrashOnCtrlScroll registry value must be configured correctly.
• Windows must be restarted after configuring the registry value.
• The keyboard shortcut may not work if the system is frozen in a state where the keyboard input cannot be processed.
• Crash dump generation depends on the system's dump configuration and whether Windows can successfully write the dump.

For systems with both built-in and external keyboards, the appropriate registry configuration may need to be considered for more than one keyboard driver.

How to Prevent Accidental 0x000000E2 Crashes

If your organization does not use keyboard-initiated crash dumps, consider the following precautions:

• Remove the CrashOnCtrlScroll registry value from keyboard drivers where the feature is not required.
• Restrict access to kernel debugging tools to authorized personnel.
• Document diagnostic procedures that deliberately generate system crashes.
• Inform support staff about the keyboard combination used to trigger a manual crash.
• Perform crash-dump testing on dedicated test computers or controlled virtual machines.
• Save important work before performing any debugging operation that may stop Windows.

Security and Data Protection Considerations

Memory dump files can contain information that was present in system memory when the crash occurred. Depending on the dump type and system activity, this information may include portions of documents, application data, credentials, or other sensitive material.

Follow these precautions when handling dump files:

• Share diagnostic files only with authorized support personnel.
• Use an approved secure file-transfer method.
• Restrict access to memory dump files.
• Follow your organization's data-retention and deletion policies.
• Do not upload memory dumps to public forums or untrusted websites.

Frequently Asked Questions

1. What does stop code 0x000000E2 mean?

It means Windows received a deliberate request to initiate a system crash. The error is named MANUALLY_INITIATED_CRASH and is commonly used to generate a diagnostic memory dump.

2. Is MANUALLY_INITIATED_CRASH a hardware problem?

No. The 0xE2 bug check does not independently indicate defective RAM, a failing hard drive, a damaged motherboard, or another hardware fault. It indicates that a manual crash request was issued.

3. Which keyboard shortcut triggers error 0xE2?

When keyboard-initiated crash functionality is enabled, hold the rightmost Ctrl key and press Scroll Lock twice. This deliberately initiates a system crash.

4. What is CrashOnCtrlScroll?

CrashOnCtrlScroll is a Windows registry value used to enable keyboard-initiated crash functionality for supported keyboard drivers. A REG_DWORD value of 1 enables the feature.

5. Does Windows always create a MEMORY.DMP file after error 0xE2?

No. Dump creation depends on the configured crash dump settings, available storage, and successful completion of the dump-writing process. Crash dumps may also be disabled.

6. Can WinDbg cause the MANUALLY_INITIATED_CRASH error?

Yes. During kernel-mode debugging, the WinDbg or KD .crash command can deliberately trigger bug check 0xE2 on the target computer.

7. Does error 0xE2 identify the faulty driver?

No. Microsoft documents no additional bug check parameters for 0xE2. If the crash was generated to investigate a previous system freeze, the complete dump and other diagnostic evidence must be examined.

8. Should I reinstall Windows to fix stop code 0x000000E2?

Not as an initial troubleshooting step. First determine whether the crash was deliberately initiated through a keyboard shortcut or debugging tool. Reinstalling Windows does not address the reason for a manual crash request.

9. Can I disable the keyboard crash shortcut?

Yes. If it is not required for diagnostic purposes, you can remove the CrashOnCtrlScroll registry value from the relevant keyboard driver configuration. Back up the registry key and restart Windows after making the change.

Conclusion

Windows stop code 0x000000E2 MANUALLY_INITIATED_CRASH indicates that a deliberate crash request was sent through a configured keyboard shortcut or a kernel debugging tool. It is generally a diagnostic mechanism rather than evidence of an independent hardware or driver failure.

If the error appears unexpectedly, investigate the keyboard shortcut configuration, recent debugging activity, and Windows event logs. If the crash was generated to investigate a system freeze, preserve the memory dump and analyze it with WinDbg to look for evidence of the original problem.

Official Microsoft References

• Microsoft Learn – Bug Check 0xE2: MANUALLY_INITIATED_CRASH
• Microsoft Learn – Forcing a System Crash from the Keyboard
• Microsoft Learn – Forcing a System Crash from the Debugger
• Microsoft Learn – Forcing a System Crash
• Microsoft Learn – Analyzing a Kernel-Mode Dump File with WinDbg