Macbook Pro - shuts down for no reason

[robwainwright]

I am not in front of my mac at the moment to test but you should be able to use either of these commands to keep a process running while still closing the terminal:

yes > /dev/null & exit

OR

nohup yes > /dev/null &

Ill share my script to run it at startup when I get back in front of my mac

BUT you are right we shouldn't need workarounds to run $2K hardware
[doublepost=1502397608][/doublepost]I just tested this and it works as advertised. Here is a quick way to create a startup script to do this automatically at login:


start Automator.app
Select "Application"
click "Show library" in the toolbar (if hidden)
Add "Run shell script" (from the Actions/Utilities)
type in "yes > /dev/null &"
Save it somewhere(documents folder, or desktop or applications folder), as "something.command" (example "workaround.command")
Go to System Preferences -> Accounts -> Login items
Add this new app as a startup item under your user account
done
logout and log back in to test

 

[UnknownUser2208]

I easily fixed the issue by keeping 1 core running 100%. Simply run

yes > /dev/null &

And don't close the terminal (or run it at startup, etc). This 100% solved the issue. Accidentally closing the terminal (making all cores go to 0%) effectively causes the crash. Keeping at least 1 core at 100%, I was able to run 20 days straight with no crashes.

I've heard about the HDMI fix... Just guessing here... maybe connecting the HDMI causes a small process to be run and so it doesn't crash. I never got to test it.

Thanks for the info! I was having the same problem and this fixed it.

 

[phorvath]

Hi there! Could someone please tell me if there was a permanent solution to this problem? I'm struggling with this for 2 weeks now.

It's a late-2013 MBP and suddenly started to shutdown randomly. I ran every test I could (diagnostics, memory, disk aid), reset SMC, NVRAM, reinstalled the OS a few times (clean install too). I took it to an official Apple retail service and they said there wasn't any hardware issue. It was full of dust though but they cleaned it and applied fresh thermal grease. I brought the machine home, started to reinstall some apps then boom, same problem, system shuts down. It runs High Sierra but I guess it is not OS related because the issue started to occur only after a month following the upgrade to HS. I tried to install the latest nVidia Web Driver (WebDriver-378.10.10.10.25.103) but it didn't help either.

None of the console logs contain any relevant information, no kernel panics. EtreCheck shows no problem, only the shutdown with cause -128 (which is unknown / general). I tried to drain the battery then plug it in, do an SMC reset but it didn't help either.

I tried the aforementioned shell script hack. The machine didn't shut down while it was running, but it is not a great solution as it is constantly drains power and generates heat by keeping a CPU core busy.

I'm quite f***ed since I use this machine for work but I'm kind of tired of investigating this nasty bug on my own. Have any of you tried to downgrade to Sierra and did it help? Was there anything working for you?

Thanks in advance.

 

[BastianS]

Hi there! Could someone please tell me if there was a permanent solution to this problem? I'm struggling with this for 2 weeks now.

It's a late-2013 MBP and suddenly started to shutdown randomly. I ran every test I could (diagnostics, memory, disk aid), reset SMC, NVRAM, reinstalled the OS a few times (clean install too). I took it to an official Apple retail service and they said there wasn't any hardware issue. It was full of dust though but they cleaned it and applied fresh thermal grease. I brought the machine home, started to reinstall some apps then boom, same problem, system shuts down. It runs High Sierra but I guess it is not OS related because the issue started to occur only after a month following the upgrade to HS. I tried to install the latest nVidia Web Driver (WebDriver-378.10.10.10.25.103) but it didn't help either.

None of the console logs contain any relevant information, no kernel panics. EtreCheck shows no problem, only the shutdown with cause -128 (which is unknown / general). I tried to drain the battery then plug it in, do an SMC reset but it didn't help either.

I tried the aforementioned shell script hack. The machine didn't shut down while it was running, but it is not a great solution as it is constantly drains power and generates heat by keeping a CPU core busy.

I'm quite f***ed since I use this machine for work but I'm kind of tired of investigating this nasty bug on my own. Have any of you tried to downgrade to Sierra and did it help? Was there anything working for you?

Thanks in advance.

Hey man, I have exactly the same problem as you described...do you have any news on that problem?!

 

[MrAverigeUser]

perhaps it is the HDD-cable?

 

[cloudnine20]

Hi there! Could someone please tell me if there was a permanent solution to this problem? I'm struggling with this for 2 weeks now.

It's a late-2013 MBP and suddenly started to shutdown randomly. I ran every test I could (diagnostics, memory, disk aid), reset SMC, NVRAM, reinstalled the OS a few times (clean install too). I took it to an official Apple retail service and they said there wasn't any hardware issue. It was full of dust though but they cleaned it and applied fresh thermal grease. I brought the machine home, started to reinstall some apps then boom, same problem, system shuts down. It runs High Sierra but I guess it is not OS related because the issue started to occur only after a month following the upgrade to HS. I tried to install the latest nVidia Web Driver (WebDriver-378.10.10.10.25.103) but it didn't help either.

None of the console logs contain any relevant information, no kernel panics. EtreCheck shows no problem, only the shutdown with cause -128 (which is unknown / general). I tried to drain the battery then plug it in, do an SMC reset but it didn't help either.

I tried the aforementioned shell script hack. The machine didn't shut down while it was running, but it is not a great solution as it is constantly drains power and generates heat by keeping a CPU core busy.

I'm quite f***ed since I use this machine for work but I'm kind of tired of investigating this nasty bug on my own. Have any of you tried to downgrade to Sierra and did it help? Was there anything working for you?

Thanks in advance.

I have a mid-2015 MBP 15" and been experiencing the same random freezing and shutdown issue. I literally did every single test you mentioned and visited the Apple Store, Genius Bar could not find any problems. Oddly enough, my MacBook froze and shutdown as I was writing this so had to rewrite my post. I am going to visit the Apple Store one last time before I give up on this defected MacBook.

 

[Isaac Cross]

I guess I'm late to this party, but I'm curious if anyone has heard of any more instances of this issue? Is anyone searching for solutions to their mysterious MBP shut down problem and coming across this forum page?

About a month and a half ago, I would have said my mid-2014 MBP was the smoothest and least troublesome computer I've ever owned. It handled tons of work and projects with ease, had strong battery life, and rarely hiccupped for any reason. Then, after one long day, I opened Netflix and my screen went dark. The fan ran hot for about 10 seconds, then the screen went black. My laptop was off.

It was shocking, not because I hadn't experienced an unexpected shutdown before with a laptop, but because I'd never experienced anything remotely suggesting a problem on this particular computer which, at this time, is still under 4 years old. After that first shutdown, I worked for weeks terrorized by this sudden black screen. Beyond the fact that video seemed more likely to trigger it, and that it would happen in consecutive bursts (effectively killing any work session), I couldn't isolate or attribute the problem.

Three Geniuses at Apple spent about a week, in person and over phone, telling me to update my operating system. I do a lot of creative projects and avoid updating as much as possible for compatibility issues. But I was at wit's end with this problem. I updated, and several things changed: I lost the ability to use several third-party programs I relied on, some directories were altered or missing, and my laptop, without question, ran noticeably, and booted considerably, slower. By this point, I was crushed to find it did nothing to curb the sudden shutdowns. Some weeks of stress later, I came across this forum post.

@smorhaim and @robwainwright's script to keep 1 core running at 100% instantly solved the problem for me. I was completely thrilled when I came across it. I didn't (and still don't) understand exactly what it does and why it works. All I know is my MBP doesn't shut down when I keep this script running.

The bewildering issue began right in the middle of a particularly intense and busy work time for me, so when this script solved it, I tried my best to carry on and catch up on all my work. It is now several weeks later. I have set up to work more from the office desktop, and without relying on my MBP so much, I have a much better perspective on the machine in front of me.

The shutdowns are no more, but running this script BURNS my MBP. It runs hot and loud, and battery life is at best a quarter of what it should be. The computer is hysterical and just holding the thing feels wrong. The fan noise also prohibits me from doing the number one thing I bought the computer to do: audio recording. Disable the script and the computer looks, feels and sounds pristine and works effortlessly - until it shuts down again.

I have done some research and learned there was a graphics issue with earlier Retina MBPs. The only intuition I have from my experience with this problem tells me it is also somehow linked to the graphics card. Based on the replies on this thread, I also get the sense that it is a fairly prevalent problem that calls for more organization than a 2-page forum post. I urge anyone who has come across this thread for similar reasons to post here and share your story.

This is my first MBP. It was a bit of a leap of faith - the most expensive computer purchase I ever made. When I bought it, I gifted my Toshiba laptop to my father. He has since used it every day professionally and it is still running beautifully after 9 years.

 

[hobowankenobi]

Just wondering...

Does it take 100% to prevent a crash, or something will something lower suffice? If not...

FYI for anybody that has this issue and wants to test...you could try running the free and easy-to-adjust System Load...and see if a lighter load would still prevent crashes, without eating so much battery and generating so much heat.

 

[maks37]

Same issue on my Late 2013 MBPR — have been using the script since November last year. Glad that I got it working, but I also realize that reselling it when the time comes won't be easy (or I'll have to let my karma take the blow).

 

[Sheldonsuckz]

Really frustrating that there is no fix yet. The work around provided is only a stop-gap that will hopefully let my computer last maybe a year more. I have a late 2013 retina 15 inch MacBook Pro running 10.13.6 and I will be going to the apple store in a few days to see what these geniuses have to say.

 

[FreePMS]

I had a customer with this problem, and SystemLoad at 10% on one core (its minimal setting) was enough to keep her up and running. HTH

 

[Sheldonsuckz]

So I had actually posted this on the apple discussions. You can follow my story here: https://discussions.apple.com/message/33795328#33795328
Basically the final part of the story is that the SSD was causing the shut down for me. The trick posted above in this thread still worked but the repair depot determined it was a failing SSD. With my computer back and working I guess I would recommend anyone with this problem to try to boot on an external drive first.

 

[Isaac Cross]

I had a customer with this problem, and SystemLoad at 10% on one core (its minimal setting) was enough to keep her up and running. HTH

I would be ecstatic if this works. Anything to shut the fan up at this point.

Could someone post instructions on how to keep the core running at 10% rather than 100%?
[doublepost=1536959236][/doublepost]

Just wondering...

Does it take 100% to prevent a crash, or something will something lower suffice? If not...

FYI for anybody that has this issue and wants to test...you could try running the free and easy-to-adjust System Load...and see if a lighter load would still prevent crashes, without eating so much battery and generating so much heat.

I've used this to keep the core at 10% in place of the script and so far no shut downs. Thanks so much for the tip.

 

[hobowankenobi]

I would be ecstatic if this works. Anything to shut the fan up at this point.

Could someone post instructions on how to keep the core running at 10% rather than 100%?
[doublepost=1536959236][/doublepost]

I've used this to keep the core at 10% in place of the script and so far no shut downs. Thanks so much for the tip.

To pretty up the ugly ghetto patch as much as possible....make it startup or log in item. One less thing to fiddle with.

 

[Isaac Cross]

To pretty up the ugly ghetto patch as much as possible....make it startup or log in item. One less thing to fiddle with.

Spoke too soon. Shutdowns like regular with SystemLoad running at 10. Also tried 20, 50 . . .even 100! All bust.

I'm not sure if I'm doing something wrong. I have SystemLoad as a startup item and it's clearly active, just moved mostly out of screen (it can't be minimized). When I check Activity Monitor System Load is usually working at the set load, but once in a while I check and it shows 0 usage. When this happens, I click the SL window, then it shows up again at the set load.

How the mystery grows . . . it looks like either SystemLoad is going to sleep on me and that's when I get a shut down - or the usage of the core doesn't have any effect on the problem.

Either way, I'm back to the script :'(

 

[hobowankenobi]

Spoke too soon. Shutdowns like regular with SystemLoad running at 10. Also tried 20, 50 . . .even 100! All bust.

I'm not sure if I'm doing something wrong. I have SystemLoad as a startup item and it's clearly active, just moved mostly out of screen (it can't be minimized). When I check Activity Monitor System Load is usually working at the set load, but once in a while I check and it shows 0 usage. When this happens, I click the SL window, then it shows up again at the set load.

How the mystery grows . . . it looks like either SystemLoad is going to sleep on me and that's when I get a shut down - or the usage of the core doesn't have any effect on the problem.

Either way, I'm back to the script :'(

Huh.

Forgot about the no minimizing...makes sense how the OS tries to release resources from minimized apps. Might be hard/impossible to program around that. Only ever used it to test hardware, never a need to minimize.

Not sure about the issue of if seeming to go to sleep or deactivate. Is the OS going to sleep, or drive sleeping? Anything besides the monitor sleeping might be an issue causing the apparent pause. You have moved the app out of the disk image I presume?

If it can be made to run continuously (as expected), might be a good time to run a second virtual desktop, and park SL there, so running, but not in the way.

 

[Isaac Cross]

Huh.

Forgot about the no minimizing...makes sense how the OS tries to release resources from minimized apps. Might be hard/impossible to program around that. Only ever used it to test hardware, never a need to minimize.

Not sure about the issue of if seeming to go to sleep or deactivate. Is the OS going to sleep, or drive sleeping? Anything besides the monitor sleeping might be an issue causing the apparent pause. You have moved the app out of the disk image I presume?

If it can be made to run continuously (as expected), might be a good time to run a second virtual desktop, and park SL there, so running, but not in the way.

Far as I can tell no part of the OS is going to sleep. I am actively using the computer (browsing, editing, loading programs) with SystemLoad dragged off screen so barely a corner shows. I also have Activity Monitor open to occasionally check what SL is doing.

When working, SL naturally sits near the top of the CPU list in Activity Monitor, but sometimes it won't be there at all. When it's not there, I search it and Activity Monitor locates it with 0 CPU usage. This has happened a few times with SL dragged off screen. When I drag SL back or select its window, it apparently gets reactivated, and reappears with high usage again in Activity Monitor.

I also noticed that the usage exerted by SystemLoad when it is working, according to AM, is very inconsistent. It will, for instance, hover around 20 when set to 10 and fluctuate generally. This is unlike "the script", which always sits at about 99.

Don't know if anyone could confirm any of what I'm finding with SystemLoad. Since it is a diagnostic program, I get the impression that it has some picky operation, can't run in the background, or otherwise is not meant to truly run continuously.

 

[mosha parker]

I am not in front of my mac at the moment to test but you should be able to use either of these commands to keep a process running while still closing the terminal:

yes > /dev/null & exit

OR

nohup yes > /dev/null &

Ill share my script to run it at startup when I get back in front of my mac

BUT you are right we shouldn't need workarounds to run $2K hardware
[doublepost=1502397608][/doublepost]I just tested this and it works as advertised. Here is a quick way to create a startup script to do this automatically at login:


start Automator.app
Select "Application"
click "Show library" in the toolbar (if hidden)
Add "Run shell script" (from the Actions/Utilities)
type in "yes > /dev/null &"
Save it somewhere(documents folder, or desktop or applications folder), as "something.command" (example "workaround.command")
Go to System Preferences -> Accounts -> Login items
Add this new app as a startup item under your user account
done
logout and log back in to test

Hey Rob, Thank you so much for your tip. It seems to work, the Yes task seems to resolve the shutting down problem.
But, in fact, even if I am not a technical geek, I like to understand what I am doing. And I wonder 2 things:
- What is the source of the problem?
- Is there a way to solve it without using the yes script that uses over 90% of the CPU ?

I am worry because I use the computer mainly to do video editing. And charging the CPU with this back task might slow down the rendering.

Thank you so much for your help !!!

Mosha

 

[timelessbeing]

I have the same problem with my late 2014 rMBP 15".
I followed the instructions here and it stopped shutting off:
https://outluch.wixsite.com/rmbp-crash

 

[joebeazelman]

After spending way too much time on this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever encountered and behaves not unlike a virus. It is silent and strikes without logs or error messages, leaving you completely baffled as to the cause. If you’re getting a proper kernel panic (i.e. dialog after restart), then you’re having a completely different problem.

As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. I also discovered deleting the Thunderbolt Ethernet Adapter profiles as well as any associated NVRAM variables also resolves the issue without disabling the drivers. These solutions, however, don't explain why some MBPs of the same model numbers do not exhibit the shutdown problem, or why it doesn't occur under Bootcamp Windows, or why zapping the NVRAM/PRAM does nothing.

When you plug in a Thunderbolt ethernet adapter, AppleThunderboltNHI.kext loads and creates the NVRAM parameters and network profiles. The NVRAM is needed to ensure a network configured connection during Recovery Mode. MacOS loads the driver based on the parameters even without the adapter present to support hot plugging. This is why clearing the NVRAM doesn't work. It only clears the values of the parameters, not the parameter variables which clues MacOS to load the driver.

Unfortunately, AppleThunderboltNHI.kext is buggy and throws a fit when it detects there's nothing connected to the Thunderbolt port and silently shuts down the system. The event isn't random as it occurs during certain network operations.

Consequently, by merely plugging your MBP to an ethernet Adapter once, it triggers the scenario for the random shutdowns. If you're having this issue, you can disable the driver, remove the NVRAM variables (NVRAM command) and Network Profiles or plug in a Thunderbolt device to keep the driver happy. If you're having this issue and you've never plugged in a Network Adapter, think really hard. Did you lend it to someone or purchase it from someone who has? Did you take your MBP to an AppleStore or Service provider and had a diagnostics performed? The dongle they attached to your Thunderbolt port was an Ethernet Adapter.

 

[orqa]

After spending way too much time on this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever encountered and behaves not unlike a virus. It is silent and strikes without logs or error messages, leaving you completely baffled as to the cause. If you’re getting a proper kernel panic (i.e. dialog after restart), then you’re having a completely different problem.

As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. I also discovered deleting the Thunderbolt Ethernet Adapter profiles as well as any associated NVRAM variables also resolves the issue without disabling the drivers. These solutions, however, don't explain why some MBPs of the same model numbers do not exhibit the shutdown problem, or why it doesn't occur under Bootcamp Windows, or why zapping the NVRAM/PRAM does nothing.

When you plug in a Thunderbolt ethernet adapter, AppleThunderboltNHI.kext loads and creates the NVRAM parameters and network profiles. The NVRAM is needed to ensure a network configured connection during Recovery Mode. MacOS loads the driver based on the parameters even without the adapter present to support hot plugging. This is why clearing the NVRAM doesn't work. It only clears the values of the parameters, not the parameter variables which clues MacOS to load the driver.

Unfortunately, AppleThunderboltNHI.kext is buggy and throws a fit when it detects there's nothing connected to the Thunderbolt port and silently shuts down the system. The event isn't random as it occurs during certain network operations.

Consequently, by merely plugging your MBP to an ethernet Adapter once, it triggers the scenario for the random shutdowns. If you're having this issue, you can disable the driver, remove the NVRAM variables (NVRAM command) and Network Profiles or plug in a Thunderbolt device to keep the driver happy. If you're having this issue and you've never plugged in a Network Adapter, think really hard. Did you lend it to someone or purchase it from someone who has? Did you take your MBP to an AppleStore or Service provider and had a diagnostics performed? The dongle they attached to your Thunderbolt port was an Ethernet Adapter.

[doublepost=1567668383][/doublepost]

After spending way too much time on this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever encountered and behaves not unlike a virus. It is silent and strikes without logs or error messages, leaving you completely baffled as to the cause. If you’re getting a proper kernel panic (i.e. dialog after restart), then you’re having a completely different problem.

As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. I also discovered deleting the Thunderbolt Ethernet Adapter profiles as well as any associated NVRAM variables also resolves the issue without disabling the drivers. These solutions, however, don't explain why some MBPs of the same model numbers do not exhibit the shutdown problem, or why it doesn't occur under Bootcamp Windows, or why zapping the NVRAM/PRAM does nothing.

When you plug in a Thunderbolt ethernet adapter, AppleThunderboltNHI.kext loads and creates the NVRAM parameters and network profiles. The NVRAM is needed to ensure a network configured connection during Recovery Mode. MacOS loads the driver based on the parameters even without the adapter present to support hot plugging. This is why clearing the NVRAM doesn't work. It only clears the values of the parameters, not the parameter variables which clues MacOS to load the driver.

Unfortunately, AppleThunderboltNHI.kext is buggy and throws a fit when it detects there's nothing connected to the Thunderbolt port and silently shuts down the system. The event isn't random as it occurs during certain network operations.

Consequently, by merely plugging your MBP to an ethernet Adapter once, it triggers the scenario for the random shutdowns. If you're having this issue, you can disable the driver, remove the NVRAM variables (NVRAM command) and Network Profiles or plug in a Thunderbolt device to keep the driver happy. If you're having this issue and you've never plugged in a Network Adapter, think really hard. Did you lend it to someone or purchase it from someone who has? Did you take your MBP to an AppleStore or Service provider and had a diagnostics performed? The dongle they attached to your Thunderbolt port was an Ethernet Adapter.

After spending way too much time on this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever encountered and behaves not unlike a virus. It is silent and strikes without logs or error messages, leaving you completely baffled as to the cause. If you’re getting a proper kernel panic (i.e. dialog after restart), then you’re having a completely different problem.

As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. I also discovered deleting the Thunderbolt Ethernet Adapter profiles as well as any associated NVRAM variables also resolves the issue without disabling the drivers. These solutions, however, don't explain why some MBPs of the same model numbers do not exhibit the shutdown problem, or why it doesn't occur under Bootcamp Windows, or why zapping the NVRAM/PRAM does nothing.

When you plug in a Thunderbolt ethernet adapter, AppleThunderboltNHI.kext loads and creates the NVRAM parameters and network profiles. The NVRAM is needed to ensure a network configured connection during Recovery Mode. MacOS loads the driver based on the parameters even without the adapter present to support hot plugging. This is why clearing the NVRAM doesn't work. It only clears the values of the parameters, not the parameter variables which clues MacOS to load the driver.

Unfortunately, AppleThunderboltNHI.kext is buggy and throws a fit when it detects there's nothing connected to the Thunderbolt port and silently shuts down the system. The event isn't random as it occurs during certain network operations.

Consequently, by merely plugging your MBP to an ethernet Adapter once, it triggers the scenario for the random shutdowns. If you're having this issue, you can disable the driver, remove the NVRAM variables (NVRAM command) and Network Profiles or plug in a Thunderbolt device to keep the driver happy. If you're having this issue and you've never plugged in a Network Adapter, think really hard. Did you lend it to someone or purchase it from someone who has? Did you take your MBP to an AppleStore or Service provider and had a diagnostics performed? The dongle they attached to your Thunderbolt port was an Ethernet Adapter.

Joe, I've been using your solution to fix this issue for years, adding .BAK to the .kext file but I just updated to 10.14.6 and that file can't be changed now. Please help me. It shuts down so often, I'm afraid I won't be able to finish my reply. I was right. It won't let me change that extensuion name. I am confused I could force it to but I have to follow every little direction you give, so I'm lost

 

[orqa]

[doublepost=1567668383][/doublepost]



Joe, I've been using your solution to fix this issue for years, adding .BAK to the .kext file but I just updated to 10.14.6 and that file can't be changed now. Please help me. It shuts down so often, I'm afraid I won't be able to finish my reply.

I'm not savy so I have to copy what you say word for word, like restart

After spending way too much time on this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever encountered and behaves not unlike a virus. It is silent and strikes without logs or error messages, leaving you completely baffled as to the cause. If you’re getting a proper kernel panic (i.e. dialog after restart), then you’re having a completely different problem.

As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. I also discovered deleting the Thunderbolt Ethernet Adapter profiles as well as any associated NVRAM variables also resolves the issue without disabling the drivers. These solutions, however, don't explain why some MBPs of the same model numbers do not exhibit the shutdown problem, or why it doesn't occur under Bootcamp Windows, or why zapping the NVRAM/PRAM does nothing.

When you plug in a Thunderbolt ethernet adapter, AppleThunderboltNHI.kext loads and creates the NVRAM parameters and network profiles. The NVRAM is needed to ensure a network configured connection during Recovery Mode. MacOS loads the driver based on the parameters even without the adapter present to support hot plugging. This is why clearing the NVRAM doesn't work. It only clears the values of the parameters, not the parameter variables which clues MacOS to load the driver.

Unfortunately, AppleThunderboltNHI.kext is buggy and throws a fit when it detects there's nothing connected to the Thunderbolt port and silently shuts down the system. The event isn't random as it occurs during certain network operations.

Consequently, by merely plugging your MBP to an ethernet Adapter once, it triggers the scenario for the random shutdowns. If you're having this issue, you can disable the driver, remove the NVRAM variables (NVRAM command) and Network Profiles or plug in a Thunderbolt device to keep the driver happy. If you're having this issue and you've never plugged in a Network Adapter, think really hard. Did you lend it to someone or purchase it from someone who has? Did you take your MBP to an AppleStore or Service provider and had a diagnostics performed? The dongle they attached to your Thunderbolt port was an Ethernet Adapter.

[doublepost=1567668990][/doublepost]

I'm not savy so I have to copy what you say word for word, like restart

OK, I just plugged into the thunderbolt hole hoping it will keep it running but it is really annoying.

 

[joebeazelman]

[doublepost=1567668383][/doublepost]



Joe, I've been using your solution to fix this issue for years, adding .BAK to the .kext file but I just updated to 10.14.6 and that file can't be changed now. Please help me. It shuts down so often, I'm afraid I won't be able to finish my reply. I was right. It won't let me change that extensuion name. I am confused I could force it to but I have to follow every little direction you give, so I'm lost

[automerge]1570039296[/automerge]
I'm not sure what you're doing, but are you following these direction:

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

 

[joebeazelman]

I have some interesting new information and a question or everyone who has been afflicted by the random shutdown issue.

I have another 2013 13" laptop and it's starting to exhibit a similar issue. One application pushed the limits of the CPU and with no kernel panic, the machine suddenly rebooted. When it restarted, everything was fine. It happened again when I ran the application again. I noticed a message "CPU is burning up" in my logs.

What I haven't mentioned yet is that I have been getting battery service warnings in MacOS on my 2013 over the past few month. On my 2014, I don't get any, but Apple's diagnostics warns that the battery needs replacement. In both cases, this happens whether the machine is plugged in or not.

Now for my question to those afflicted. Please let me know the condition of your battery. Do you receive any messages about your battery? If not, does your battery drain quickly or can't hold a charge for very long? Run Apple's diagnostic diagnostics by following the instructions below:

Diagnose problems on Mac

If your Mac doesn’t start up using macOS, try using Apple Diagnostics.

support.apple.com

I am trying to find out if this is related to a bug in the power management unit.

 

[VHK]

hi, just registered to chime in on an old (if not dead) thread.

2014 MBP, 15" retina. started randomly shutting down - first with kernel panics (running netflix on safari, which is not a hot idea apparently), then the dreaded instant black screen dropouts. not even sure if the two are related.

for the record, i was still running Yosemite when the instant shutdowns started, so it's not exclusive to Sierra or any other OS. sometimes it doesn't happen for hours, sometimes i don't even get the time to start up any apps after reboot.

reinstalled OS, tried SMC and PRAM resets, upgraded to Sierra, you name it.
only thing that worked remotely was booting in Safe Mode, but since i mainly work on audio projects that's not really a viable option. but it did confirm that it's probably not hardware related..
and then i came across this thread.

i have used a Thunderbolt to ethernet adapter in the past, but it seems such a long time ago that i find it hard to relate it to the dropouts, timewise. a LOT of carefree time in between the last use of the adapter and the problems. nonetheless, i AM currently trying the thunderbolt kext fix. seems to work for now - will see how well that holds up.

anyway: i ran diagnostics earlier, and i got this:
"The battery will need to be replaced soon. it is functioning normally, but holds less charge than it did when it was new. reference code PPT002." hope that helps.

-----

p.s. i couldn't get all the terminal commands to work for me, so here's how i went about it:

1) reboot with CMD+R pressed to enter recovery mode
2) open Utilities > Terminal
3) type "csrutil disable" + enter
4) reboot with SHIFT pressed to enter safe mode (normal mode crashed too often..)
5) navigate to, and select, HD > system > library > extensions > AppleThunderboltNHI.kext
6) CMD+i for info. add ".BAK" to name manually
6) reboot with CMD+R pressed, open terminal
7) type "csrutil enable" + enter.

man, i sure hope that this is THE fix.
good to know i'm not alone..