What Is M112 Shutdown in Marlin Firmware? (What Causes It?)

While the occurrence of an M112 shutdown is signified clearly by a message that pops up on the screen of the 3D printer, this message alone doesn’t provide a whole lot of information about what an M112 shutdown really is and what could cause it to happen in an unexpected manner.

In this guide, we will explain what an M112 shutdown is in Marlin firmware, go through the problems that can cause your 3D printer to have an unexpected M112 shutdown, and discuss how you can fix such issues in a convenient manner.

What Is M112 Shutdown in Marlin Firmware?

An M112 shutdown in Marlin Firmware is an immediate shutdown that occurs as a result of sending the M112 G-code command to the 3D printer, which practically prompts the firmware to shut off all the components of the 3D printer it has access to, whether it’s the heater or the stepper motors, and put the 3D printer into a state where it requires a reset to be operational again.

marlin m112 shutdown

The most common use case of the M112 G-code command, as you may predict, is when the firmware or the 3D printing interface you’re using calls it internally to trigger an emergency shutdown, which is how you can end up being greeted by the M112 Shutdown message on your 3D printer’s LCD controller in an unexpected manner, with your print canceled halfway.

In such a scenario, your 3D printer getting shut down with the M112 G-Code command practically means an unrecoverable error that would make it impossible for the printing process to continue correctly has occurred, which we will discuss in more detail in the upcoming section.

With that said, it’s also worth mentioning that it’s possible to trigger an M112 shutdown manually through a G-code terminal if necessary, similar to using any other G-code command available, and while this command is one that you most likely won’t need to utilize under normal circumstances, it’s still one to keep in mind as it can be handy in some cases, such as when you can see that a print has failed through a camera, but are unable to reach the 3D printer physically to switch it off at the moment.

For a manually-sent M112 command to be able to jump in front of the command queue and halt your 3D printer instantly without having to wait for a space to open up in the queue, which can take some time depending on the commands your 3D printer is running at the time, you will need to ensure that the EMERGENCY_PARSER variable is active in the Marlin Firmware configuration.

What Can Cause an M112 Shutdown on Your 3D Printer? (and How to Fix It?)

While an M112 shutdown means that the firmware is shutting the 3D printer down immediately, which effectively tells us that a situation where the 3D printer cannot continue operating anymore has occurred, the fact that there are a fair few possible factors leading to such a scenario makes things slightly challenging when it comes to finding the root cause.

Below is a list of the most common issues that can cause your 3D printer to have an M112 shutdown, along with the solutions we recommend applying, which you can use as a checklist to find the culprit creating the issue in your case.

OctoPrint Error Handling Configuration

According to the community reports we have seen, the majority of the unexpected M112 shutdown issues occur due to OctoPrint’s error handling feature being configured in a particular way that causes it to automatically send M112 if it’s about to disconnect from the 3D printer as a result of an error.

octoprint m112 shutdown example

While this OctoPrint feature is designed to shut things off in the case of fatal errors that would practically make it impossible for the print to continue anyway, such as a thermal runaway, there can also be cases where OctoPrint ends up sending M112 for something non-critical, such as receiving an unexpected response from the 3D printer (which can happen due to incompatibilities between firmware and OctoPrint sometimes), a hiccup during the establishment of the serial connection, or picking up an error message that doesn’t necessarily warrant a shutdown.

A couple of common examples of such cases are the “Probing Failed” error in Marlin that can occur as a result of an automatic bed leveling probe not being able to complete the probing process and the “Checksum Mismatch” error that can take place when USB printing with a G-code file that has a very long filename as a result of the length of the filename exceeding the serial connection buffer limit, which you can view in the OctoPrint terminal log once they occur.

Additionally, it’s also worth mentioning that while the “Probing Failed” error would display its unique error message on the LCD controller under normal circumstances, OctoPrint sending the M112 shutdown command to the 3D printer once it detects this error will result in the generic “M112 Shutdown” message to appear on the screen instead (you can still see the original error message in the OctoPrint terminal log as we have mentioned), which also adds to the confusion.

In fact, this behavior is also listed in the documentation pages of widely-used Marlin firmware forks, such as Professional Firmware for Ender 3 V2 / S1 and Jyers Firmware for Ender 3 V2, with developers of these firmware recommending deactivating this feature to avoid false positives that can lead to M112 shutdowns.

To find this setting in your OctoPrint dashboard, start by clicking the wrench icon on the top-right corner, which will bring up the settings menu.

octoprint settings button top bar

Next, click the Serial Connection tab from the left pane if you already aren’t in there, and click on the Behaviour tab that you can find at the top of the window.

octoprint behavior settings menu

In the scenario where (such as the image above) the What to do on a firmware error parameter is configured as disconnect from the printer or Cancel any ongoing prints but stay connected to the printer, and the Send M112 on disconnect due to error option is checked, it’s possible for you to come across a scenario where OctoPrint sends an M112 due to a non-critical error.

So, if your OctoPrint error handling settings are also configured this way, our first recommendation would be to remove the USB cable from your 3D printer, run a test print directly from the 3D printer with an SD card instead of using OctoPrint, and see whether the printing process concludes without any problems in sight, including the M112 shutdown issue you’ve been experiencing.

In the case where the problem does indeed happen again, you can skip the OctoPrint part of things for now and move on to other possible culprits, as the issue still occurring, even when you don’t use OctoPrint, tells us that OctoPrint isn’t responsible, or at least not the only responsible factor that causes for the occurrence of the shutdown.

On the other hand, if you don’t experience the problem with OctoPrint out of the equation, the next step is to adjust the error handling settings in a way that would prevent this from happening again.

For this process, open up the Behavior menu once more, as we have discussed before, choose the Ignore option for What to do on a firmware error, and uncheck the Send M112 on disconnect due to error option, which will change OctoPrint’s behavior when it encounters errors to not taking any action.

octoprint error handling changes

Provided OctoPrint was indeed the culprit of the M112 shutdowns you’re experiencing, you shouldn’t come across any M112 shutdowns after making these changes.

That being said, as OctoPrint triggering an M112 shutdown does mean that it has stumbled upon something that wasn’t supposed to be there, it will most likely be a good idea to follow up on the nature of the problem through the OctoPrint terminal logs, as such an issue can still cause your print to fail or not to start, or at least affect it negatively in some way (such as the examples we have talked about earlier), even with OctoPrint not triggering an M112 shutdown for it.

Misconfigured / Incompatible Firmware

If you aren’t using OctoPrint at all, the most likely culprit behind the M112 shutdown problem you’re facing is the usage of firmware that’s either incompatible with your 3D printer or one that’s not configured correctly in some way.

Such an issue is especially likely if you have recently switched to new firmware, especially one that you have compiled yourself with a custom configuration or one that you have obtained from a third-party source, as the chance of incompatibility or an issue with the firmware configuration will be higher in such cases.

Some of the most commonly encountered firmware-related issues occur when installing an automatic bed leveling probe but not configuring the firmware correctly, such as the example of not defining USE_Z_PROBE_FOR_HOMING in the firmware configuration after connecting the probe and disconnecting the Z endstop or defining Z_MIN_PROBE_USES_Z_ENDSTOP_PIN even though the probe is connected to the dedicated probe pin, and not the Z endstop pin.

While such issues should usually come with their own custom error message, such as “Probing Failed” for a probing-related error, the error message you observe can be the generic M112 shutdown message depending on the firmware installed on your 3D printer, as these messages can be modified by altering Marlin source code.

Regardless, our recommendation to rule out a possible firmware-related problem would be to go back to the firmware you’ve been using (and to revert the hardware changes you did at the same time) without issues, which should preferably be the official, up-to-date firmware from your 3D printer’s manufacturer (to ensure that it’s compatible), and see if the problem repeats.

Provided that the problem doesn’t occur anymore, you will now have isolated the issue to the new firmware (and the hardware modification, if any), meaning that you can focus on the configuration of the new firmware you’ll be flashing (and the wiring of the hardware) to get things back in working order, without having to worry about the possibility of any other parts of your 3D printer creating the problem.

Damaged / Incorrect Wiring & Loose Connectors

While rare, problems regarding the wiring, whether damaged wires, connectors coming loose, or wires not connected to the correct pins, can also cause the firmware to trigger an M112 shutdown in some cases.

As it’s not common for the wires to suddenly have issues out of nowhere, this is more likely to be the case if you put your 3D printer together for the first time or added a new component, such as a BLTouch automatic bed leveling sensor, which can sometimes end up with a wire being connected wrongly or another connector coming off the mainboard by accident.

Regardless, our primary recommendation, in this case, would be to start by removing all the wires between the mainboard and the components and inspecting both the wires and the connectors attached to them for damage, whether it’s bending, stripping, or connectors coming loose and changing any wires that may be compromised.

Next, reconnect all the wires to their correct spots by referring to the wiring diagram for the 3D printer/mainboard you’re using while also ensuring that all the connectors are sitting tightly in their places without any wobble.

If the problem repeats, revert the last hardware modification you have done (such as adding a BLTouch), along with the firmware change you have done to make your 3D printer compatible with the new hardware, and test again.

Provided that the issue doesn’t occur anymore, you can then focus on troubleshooting the particular hardware change you’ve made, which effectively is what’s causing the M112 shutdown in your case, and once you resolve that problem, the M112 shutdowns will also be a thing of the past.


While having your 3D printer getting stopped by an M112 shutdown isn’t a pleasant experience, especially if it occurs in the middle of a print for no apparent reason, there’s usually a reasonable explanation for the firmware to initiate this procedure, which can even protect your 3D printer’s components from damage in some cases.

That being said, finding out why the M112 shutdown has occurred in your case will most likely be a challenging process due to the many possible culprits that can lead to such an event, whether it’s an issue regarding one of the hardware components or one that’s related to the firmware configuration.