'''After speeding 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, then you’re having a completely different problem.'''
+
After speeding 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, 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, doesn'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 doesn't solve the issue.'''
+
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, doesn'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 doesn't solve the issue.
-
'''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.'''
+
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.'''
+
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.'''
+
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 speeding 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, 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, doesn't explain why some MBPs of the same model numbers do not exhibit the shutdown problem, why it doesn't occur under Bootcamp Windows or why zapping the NVRAM/PRAM doesn't solve the issue.'''
+
'''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, doesn'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 doesn't solve the issue.'''
-
'''To understand why, you need to understand how MacOS loads network drivers. Network drivers are loaded on demand when MacOS detects a network device. If it is a new one, it creates a default profile and adds parameter variables with default values in the NVRAM/PRAM area. This is how it remembers your network device settings even if you boot in recovery mode where a configured connection is sometimes required. Clearing the NVRAM clears the parameter values, but not the parameter variables. Their mere presence clues MacOS to load the associated drivers.'''
+
'''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.'''
-
'''When you plug in a Thunderbolt ethernet adapter, AppleThunderboltNHI.kext loads and creates the NVRAM parameters and network profiles. MacOS loads the driver based on the parameters even without the adapter present to support hot plugging. 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.'''
+
'''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 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 out to someone or purchase it from someone who did? Moreover, did you take your MBP to an AppleStore or service provider who performed a diagnostics? The dongle they attached to your Thunderbolt port was an Ethernet Adapter.'''
+
'''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.'''
OK. After speeding way too much time trying to solve this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever seen 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, then you’re having a completely different problem.
+
'''After speeding 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, then you’re having a completely different problem.'''
-
As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. This solution, however, doesn’t explain why some MacBook Pro machines of the same model years don’t have this issue, nor how this bug happens.
+
'''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, doesn't explain why some MBPs of the same model numbers do not exhibit the shutdown problem, why it doesn't occur under Bootcamp Windows or why zapping the NVRAM/PRAM doesn't solve the issue.'''
-
MacOS loads AppleThunderboltNHI.kext on demand whenever it detects a Thunderbolt ethernet adapter. It will also create a permanent profile for the adapter so it can easily start and configure it next time you restart the machine. MacOS loads the associated driver for each Network stored profile even if the Network even if it isn’t physically attached, since they can be added and removed at will.
+
'''To understand why, you need to understand how MacOS loads network drivers. Network drivers are loaded on demand when MacOS detects a network device. If it is a new one, it creates a default profile and adds parameter variables with default values in the NVRAM/PRAM area. This is how it remembers your network device settings even if you boot in recovery mode where a configured connection is sometimes required. Clearing the NVRAM clears the parameter values, but not the parameter variables. Their mere presence clues MacOS to load the associated drivers.'''
-
AppleThunderboltNHI.kext is buggy, however, and freaks out if it detects an empty port as exhibited by random reboots. It tends to occur during network operations such as web browsing when MacOS polls the network drivers to see if they’re present. So long as you have some device connected to the Thunderbolt port, the problem will not occur.
+
'''When you plug in a Thunderbolt ethernet adapter, AppleThunderboltNHI.kext loads and creates the NVRAM parameters and network profiles. MacOS loads the driver based on the parameters even without the adapter present to support hot plugging. 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.'''
-
To prevent the issue from happening in the first place, don’t use a Thunderbolt Ethernet Adapter unless you plan to have it or another Thunderbolt device permanently attached to your MacBook. If you have never used a Thunderbolt Ethernet Adapter but have this issue, think really hard. Did you visit your local Apple Store and had them perform a diagnostics on your machine? Yup,that’s how you got it.
+
'''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 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 out to someone or purchase it from someone who did? Moreover, did you take your MBP to an AppleStore or service provider who performed a diagnostics? The dongle they attached to your Thunderbolt port was an Ethernet Adapter.'''
OK. After speeding way too much time trying to solve this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever seen 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, then you’re having a completely different problem.
-
As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. This solution, however, doesn’t explain why some MacBook Pro machines of the same models don’t have this issue and how it happens.
+
As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. This solution, however, doesn’t explain why some MacBook Pro machines of the same model years don’t have this issue, nor how this bug happens.
-
MacOS loads AppleThunderboltNHI.kext on demand whenever it detects a Thunderbolt ethernet adapter. It will also create a permanent profile for the adapter so it can easily start and configure it next time it runs. AppleThunderboltNHI.kext is buggy,however, and freaks out if it detects an empty port as exhibited by random reboots. It tends to occur during network operations such as web browsing. So long as you have some device connected to the Thunderbolt port, the problem will not occur.
+
MacOS loads AppleThunderboltNHI.kext on demand whenever it detects a Thunderbolt ethernet adapter. It will also create a permanent profile for the adapter so it can easily start and configure it next time you restart the machine. MacOS loads the associated driver for each Network stored profile even if the Network even if it isn’t physically attached, since they can be added and removed at will.
-
So to prevent the issue from happening in the first place, don’t use a Thunderbolt Ethernet Adapter unless you plan to have it or another Thunderbolt device permanently attached. If you have never used a Thunderbolt Ethernet Adapter but have this issue, think really hard. Did you visit your local Apple Store and had them perform a diagnostics on your machine? Yup, that’s how you got it.
+
AppleThunderboltNHI.kext is buggy, however, and freaks out if it detects an empty port as exhibited by random reboots. It tends to occur during network operations such as web browsing when MacOS polls the network drivers to see if they’re present. So long as you have some device connected to the Thunderbolt port, the problem will not occur.
+
+
To prevent the issue from happening in the first place, don’t use a Thunderbolt Ethernet Adapter unless you plan to have it or another Thunderbolt device permanently attached to your MacBook. If you have never used a Thunderbolt Ethernet Adapter but have this issue, think really hard. Did you visit your local Apple Store and had them perform a diagnostics on your machine? Yup, that’s how you got it.
OK. After speeding way too much time trying to solve this issue, I discovered the source of the problem. This is one of the most evil crashes I’ve ever seen 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, then you’re having a completely different problem.
As already mentioned, you can solve this issue by simply disabling or deleting the AppleThunderboltNHI.kext. This solution, however, doesn’t explain why some MacBook Pro machines of the same models don’t have this issue and how it happens.
MacOS loads AppleThunderboltNHI.kext on demand whenever it detects a Thunderbolt ethernet adapter. It will also create a permanent profile for the adapter so it can easily start and configure it next time it runs. AppleThunderboltNHI.kext is buggy, however, and freaks out if it detects an empty port as exhibited by random reboots. It tends to occur during network operations such as web browsing. So long as you have some device connected to the Thunderbolt port, the problem will not occur.
So to prevent the issue from happening in the first place, don’t use a Thunderbolt Ethernet Adapter unless you plan to have it or another Thunderbolt device permanently attached. If you have never used a Thunderbolt Ethernet Adapter but have this issue, think really hard. Did you visit your local Apple Store and had them perform a diagnostics on your machine? Yup, that’s how you got it.