Here’s a real live detective story. 

As I have always done, I upgraded my MacBook Pro to the latest OS, especially when it’s a free upgrade. So, I dutifully made a backup and installed Mavericks. So far so good. On install success, there was no problems detected and none surfaced for some time. I noticed a problem after awaking from sleep, tried resetting the NVRAM (P-R-Command-Option held down through two POST chimes), and resetting the SMC (MacBook Pro is shut down and then hold the Shift-Control-Option and power while all cables disconnected except for MagSafe, which makes the MacBook Pro MagSafe light (actually the AC Adapter’s LED) flicker briefly) and then as the issue persisted had the MacBook Pro checked at my local Apple Store Genius Bar. The store ran their proprietary Storage Diagnostics service which gave me a SOFTWARE WARNING in a bright yellow band across the display output. This, I learned, meant that I needed to reinstall the OS to overcome any issues. 

No problem. 

I went home and booted to the Recovery Partition (command – R at the start from cold) and selected the reinstall option. 

Hours later (I guess it’s really slow from the Internet), I was able to test my MacBook Pro: same issue. Although I did the software repair as recommended by Apple, this was not the problem that I brought the MacBook Pro to the store for.

I learned by observation, to really understand the problem which was:

awake from sleep failed if the MacBook Pro had fallen asleep attached to the Thunderbolt Display. 

I built a Known-Good Boot Drive from a summer-time TimeMachine drive I had and discovered that the problem DID NOT occur with a known-good OS. This meant that my problem was SOFTWARE and I needed to narrow it down further to determine exactly what needed to be changed to make the MacBook Pro operate as expected instead of the way it was. I created a Guest user account and tested for the presence of the problem there. It was present. 

By this time, I had narrowed the test sequence to:

Attach MacBook Pro to Thunderbolt Display and startup with the appropriate test condition. Select Sleep from the Apple-menu. Noted that the display goes black instantly. The Hard Drive activity LED would eventually stop being solid and then adopts a snoring style pattern: on and then gradually fade to off on a three or four second cycle. Next, remove the Thunderbolt connection and space-bar space-bar the MacBook Pro keyboard. The correct response, with my configuration settings, is for the MacBook Pro to jump to my login screen and prompt for a password. Correct password should open the computer to the desktop running the apps previously on when put to sleep. Failure results in spinning pinwheel and ultimately a hard restart to know the MacBook Pro out of the death loop.

As the next step, I brought the MacBook Pro back to the Apple Store and wiped the drive, doing a complete repartition and restore-style installation of Mavericks. When I got home, I created a test account and ran the test. Worked correctly as expected. Then I restored from my TimeCapsule backup and ran the test. Failed. 

At this point, I’m realizing I need to do a more refined narrowing of the issue and therefore the solution. Researching my issue on, I came across an article specifying a utility called ETRECHECK. This free utility generates a report of all the extensions, plugins and old software I might have running on the MacBook Pro. It is anonymized (removes personal identifiers) and with a click, publishable onto the Clipboard. This is where I discovered that I had in operation a kernel extension related to an app that I hadn’t used in five years. Since I’ve been using TimeMachine (starting about 2007), I’ve been porting every eligible app and feature into the most current implementation of Mavericks, and that means that this little extension has been lying dormant in my kernel, waiting for me to discover it yesterday. 

The report includes:

Hardware Information:
Video Information:
Audio Plug-ins:
System Software:
Disk Information:
USB Information:
FireWire Information:
Thunderbolt Information:
Kernel Extensions:
com.ncp-e.vpn.driver.ncplbmac (1.0.1)
Problem System Launch Daemons:
Problem System Launch Agents:
Launch Daemons:
Launch Agents:
User Launch Agents:
User Login Items:
3rd Party Preference Panes:
User Internet Plug-ins::
Bad Fonts:
Old applications:
Time Machine:
Top Processes by CPU:
Top Processes by Memory:
Virtual Memory Statistics:

With this report in hand, I was able to run the utility in Safe Boot mode (all extensions off), generate a comparison report as well as run the test case. In Safe Boot, the MacBook Pro actually awoke as expected. 

The two reports told me that any of the half-dozen or so extensions on my MacBook Pro are the difference between working and not-working Wake from Sleep. I removed each one by one and tested it. Disabled Java, Printopia, ClipMenu and DropBox. The issue still occurred. As it turned out, it was the last one on my hit list: the ncp-e.vpn extension. I did a search on the “NCP Client uninstaller” and came across an article reminding me that complex apps, such as this one, often have a related uninstaller app that, as the name suggests, is capable of uninstalling the offensive app and all of its constituent elements. I scoured the web with NCP uninstaller to no avail.

Then I found this article which suggested that I should check out the Application Support folder. As I scanned my Applications and then Macintosh\ HD/Library/Application\ Support folders, I realized that I had the uninstaller in my root level Library/Application Support folder all along. Although this took hours to get to the bottom of the list, but was hugely satisfying when the actual culprit, the ncp-e.vpn driver, installed as part of a VPN client for Mac that I was writing about five years ago and carried from Mac to Mac in the Time Machine backup/restore was actually proven to be cause of the awakening issue. 


This post has already been read 0 times!