Random Shutdown on Macbook Pro (15" mid 2014)

I'm having this exact issue as well. It's already the second logic board in a row I'm having this problem with. Had the first one replaced. Honestly I have had nothing but trouble with this machine (MacBook Pro mid-2014, intel iris pro 5200). Everything is already replaced except for the base plate (which is just a piece of aluminium). Downloaded the app from https://realmacmods.com/product/macbook-pro-nocrash-utility/. Hope it works for me. After installation when you click the spinning gear icon in the top menu bar, it states 0% completed. This should stay like this right? Using the laptop for 15 minutes now. Going good so far. Thanks guys!

Yes, the Macbook pro no crash app does work. And yes that is what the app says (0%…), had not have a crash for a month now and I use to have up to 8 times in a row in a couple of hours. I have actually closed the app now (it does take a bit of power from your battery) and for some reason it still is not crashing. It is a shame that apple can’t even noticed what Real Mac Mods have managed to fix. Those guys are for real.

Is there a way in which we can band together and put some pressure on Apple about this? Maybe forcing them to replace the faulty models with a different one. I'm absolutely stoked that I have my laptop working again thanks to the Macmod guy(s). But I still think this is a little too convenient for Apple. All these laptops shutting down, leaving no crash reports, making it impossible to find the problem and always resulting in a sale of a logic board. I'm on my second one experiencing this problem. Let's find a way to put pressure on this company.

Been using macbookpronocrash app for a few weeks now, works perfectly (feels like having a new macbook)

I used my laptop all day without the app running and it did not crash. Did mbp_nocrash fix it? weird.

Also wondering why apple does not acknowledge this problem. How many are we?

I think there are quite a lot of us and the problems occur since macOS 10.12 released.

I have installed the nocrashMBP app and it did help solve the problem by running a background python script to keep the CPU waking up. I think this can only be a temporary solution because it causes more battery consumptions.

Apple should acknowledge this problem even they don't wont to replace our Logic board, they should ask the developing team to update their OS kernel to deal with this special issue. We should find a way to tell them.

1) reboot with CMD+R pressed.

2) open Terminal

3) sudo csrutil disable

4) reboot with CMD+R pressed

5) sudo mv /System/Library/Extensions/AppleThunderboltNHI.kext

/System/Library/Extensions/AppleThunderboltNHI.kext.BAK

6) csrutil enable

7) reboot and forget about problem

https://outluch.wixsite.com/rmbp-crash

They don't acknowledge this because that would mean admitting that aaaallll those people who have already bought a new logicboard for €700, did it because a fault on their side, it's a problem which already exists for a couple of years. This is scandal material.

Thanks for the method. And I have tried your way.

For my mac, I still got no luck to get rid of it. 😐

BTW, if we do step 4) and then step 5), the terminal response "read-only and cannot be moved", I move those files in the Normal mode, not in the recovery mode.

Even if all of the affected logic boards have the same issue (a sudden shut off with no log activity when running on battery with a very low CPU load), it might reveal in a bit different conditions due to tiny hardware deviations across the affected units. My 15" MacBook Pro (Late-2013, Intel i7 2GHz, Iris Pro) started to shut off a week after upgrading to High Sierra (10.13.2). That first week of using High Sierra the laptop was AC-powered 99% of the time. The issue revealed multiple times during a meeting when running on battery for about 5 hours, the first time after the upgrade. iStat Menus registered the CPU frequency dropping below 900 MHz right before the shut-offs. I noticed that NoCrashMBP holds the frequency at nominal 2 GHz by putting a 20% load on a single core. I downgraded back to Sierra (10.12.6) and no shut-offs have been observed for a few days of working on battery, without NoCrashMBP or any other thicks. Even though iStat Menus still registers the CPU frequency dropping below 900 MHz, but the ambient frequency of the integrated GPU is stable at 750 Mhz on Sierra rather than 300 MHz on High Sierra, which could prevent shut-offs on Sierra due to a higher power consumption.

Since the issue seems to be somewhere in between the SoC hardware and power management software, Apple should either recall the defective logic boards or maintain a software workaround, even at the cost of reducing power efficiency for the owners of the affected laptops.

For us here, we have two MBP Mid2014 bought at different times and with different OS. When they both started to do the same thing (shutting down for no reasons) I started to wonder… if they BOTH do that, more then likely they ALL (or a LOT of them at least) do that. So back to the thread here, how do we get Apple to pay notice? Being the old US of A, I would ask, does anyone know a lawyer who would like to get Apple to pay notice? I am saying this thinking there has to be a LOT of us out there, and yes, Apple should just do a fix that does not kill the battery life and allows us to work on our MBP for what they are worth.

Yes, of course, more of us!!! There is a fix NoCrashMBP and it works (only $10) but it eats up battery time big time and also runs the MBP a little hot I found. Otherwise no crash withMBP on. So WE know the problem (it has to do with some low frequency thing on the CPU if I get it right) but APPLE can’t get around to even acknowledge the problem publicly and write a simple fix for it. Much easier telling all of us to buy new logic board and cross our fingers…

There are solution. You will lose ability to use ethernet via thunderbolt.

PS. Today I told apple about this solution via chat. They maybe will fix it soon.

1) reboot with CMD+R pressed.

2) open Terminal

3) sudo csrutil disable

4) reboot in normal mode

5) sudo mv /System/Library/Extensions/AppleThunderboltNHI.kext

/System/Library/Extensions/AppleThunderboltNHI.kext.BAK

6) reboot with CMD+R pressed

7) csrutil enable

8) reboot and forget about problem

I agree, NoCrashMBP helps to keep some load on the CPU package, and that eats up battery. However, I'm now curious about why Sierra works for me, while High Sierra shuts down randomly. I have noticed a distinct difference in resource/power management between these versions of macOS: Sierra keeps the frequency of the integrated Intel GPU at 750 MHz when idling, High Sierra maintains much lower GPU frequency of 250 MHz. The CPU frequency management looks very similar. That's easy to check with Intel Power Gadget.

The increased GPU frequency on Sierra could be accompanied by a higher voltage of the whole CPU/GPU package, which prevents it from shutting down. On High Sierra can maintain a higher voltage by putting some load onto CPU when rinning NoCrashMBP.

Though I don't understand how it can be related to the Thunderbolt Ethernet driver.

Is the Thunderbolt Ethernet driver affected only in High Sierra? Isn't the cure just a side-effect of turning off a mandatory driver? E.g. there might be an infinite loop checking some condition related to the Ethernet driver, which could put some load on CPU and thus prevent a shutdown. Did you observe any shut offs on Sierra?

I've rolled back to Sierra, and it works fine for me now. I'd like to try your solution, but it would take a whole day to upgrade to High Sierra then downgrade back if the proposed solution won't work.

It isn't a problem related to the operating system. I've had this problem on 3 different ones. Although after a clean install the laptop maybe worked for half an hour instead of 5 minutes. After that it's business as usual. For me using a web browser seems to speed up the problem. Sometimes I could use the computer for some time and the problem just occurred after opening any webbrowser. But with NocrashMbp it doens't the problem is gone.