; Date: Sat Oct 13 2018

Tags: macOS High Sierra »»»» Kext »»»» macOS Kext »»»» iShowU Audio Capture

I needed to use OBS Studio to capture some video/audio from my desktop. On Mac OS X that in turn requires installing iShowU Audio Capture. That installation should be trivially easy, but it took me 2 weeks to work out how to get it installed, and a long email thread with the Shiny White Box support staff. The problem was the installation required that I give permission, but giving permission meant opening up the System Preferences to the Security pane and clicking on a button, and clicking on that button did not work. There is a fairly long list of possible suggestions that I have to share.

A "Kext" is a "Kernel Extension", meaning a piece of software that extends the functionality of the macOS Kernel. By the way, I'm still uncomfortable typing "macOS" after typing "Mac OS X" for the last 20 years. Apple... Why???

In the normal case, when a Kext installation requires permission a dialog is supposed to appear in front of the user. Clicking on the dialog is supposed to bring the user to the Security pane in the System Preferences. In the Security pane will be a message that an application by Such-And-So developer requires permission, and there is an Allow button. Clicking on the Allow button is supposed to bring up a dialog containing checkboxes, you tick off the checkboxes, click the OK button, and the system allows that Kext to function.

That's a nice and simple user experience. When it works. In my case, and the case of many others, clicking on the dang Allow button did nothing. The button would turn blue, but nothing would happen beyond this.

As always the recommendation to learn more is to enter relevant messages into your favorite search engine, like DuckDuckGo. Entering "Some system software was blocked from loading" into DuckDuckGo had some information but no quick fix.

Turns out that lots of people are having this issue and for many other applications.

The earliest suggestion was - make sure I'm doing this with a regular mouse or trackpad, not with a Wacom tablet, nor any other assistive device. In my case it is a MacBook Pro and I'm using the trackpad.

In the case of iShowU Audio Capture, there is a rigamarole required to carefully navigate the process. They supply an "Uninstall" application which lands in the Applications directory. So...

1. Run the Uninstall application
2. Reboot the system
3. Run the iShowU installer
4. Reboot the system

It's possible a system reboot will reset something and the Kext will load. This did not magically do the trick, but it's worth a try.

Debugging Kernel Extension installation quickly gets you into the geeky underbelly of the operating system. I was unable to find a nice GUI application to browse the Kext's and configure which does what and when.

For example there might be messages in /var/log/system.log.

In my case a key command was:

$ sudo kextload /Library/Extensions/iShowU\ Audio\ Capture.kext 
Password: 
/Library/Extensions/iShowU Audio Capture.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
$ sudo kextutil -i -v -t /Library/Extensions/iShowU\ Audio\ Capture.kext
Defaulting to kernel file '/System/Library/Kernels/kernel'
Kext rejected due to system policy: <OSKext 0x7fc9cb76dee0 [0x7fffa44caaf0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/iShowU%20Audio%20Capture.kext/", ID = "com.shinywhitebox.iShowU-Audio-Capture" }
Kext rejected due to system policy: <OSKext 0x7fc9cb76dee0 [0x7fffa44caaf0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/iShowU%20Audio%20Capture.kext/", ID = "com.shinywhitebox.iShowU-Audio-Capture" }
Diagnostics for /Library/Extensions/iShowU Audio Capture.kext:

The pathname for the Kext will vary based on which Kext you are installing. The pathname shown here is for the iShowU Audio Capture application.

The key message is: Kext rejected due to system policy

The permission grant is supposed to be handled via the Security pane but as we already determined that Security pane isn't working.

Permissions grants are stored in an SQLITE3 database which you can investigate this way:

# sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy 
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> select * from kext_policy;
|com.epson.print.kext.USBPrintClass|0|Legacy Developer: Epson|4
|com.lexmark.print.usbmerge|0|Legacy Developer: Lexmark|4
7L83S9698G|com.TrustedData.driver.VendorSpecificType00|0|Drobo, Inc.|4
7L83S9698G|com.drobo.SCSI.ThunderBolt|0|Drobo, Inc.|4
XE2XNRRXZ5|jp.co.canon.bj.print.BJUSBLoad|1|Canon Inc.|0
XE2XNRRXZ5|jp.co.canon.ij.print.CIJUSBLoad|1|Canon Inc.|0
52444FG85C|com.silabs.driver.CP210xVCPDriver|0|Silicon Laboratories Inc|4
VB5E2TV963|org.virtualbox.kext.VBoxDrv|0|Oracle America, Inc.|4
VB5E2TV963|org.virtualbox.kext.VBoxUSB|0|Oracle America, Inc.|4
VB5E2TV963|org.virtualbox.kext.VBoxNetFlt|0|Oracle America, Inc.|4
VB5E2TV963|org.virtualbox.kext.VBoxNetAdp|0|Oracle America, Inc.|4
PMJ275ZTUX|com.shinywhitebox.iShowU-Audio-Capture|0|Shiny White Box Limited|4

This database is in a write-protected area of the macOS files. This database contains the flags as to which Kext's are allowed or not. Since the database is write-protected we must do something special to modify the database.

It's possible this sequence of steps is unnecessary for solving the problem. However for the purpose of definitively resetting the policies, it is necessary to boot into Recovery mode, start a Terminal window, and then modify the database. We restart in Recovery mode because doing so makes the database writable.

1. Make sure the iShowU application is uninstalled
2. Reboot -- hold down COMMAND-R until it starts booting
3. When it enters the macOS Install/Recovery window, click on the Utilities menu, then click on the Terminal choice
4. A terminal session with root privileges starts up ... so be careful

That login session is booted off a different file system than your normal macOS installation. Instead the normal macOS disk will be available as something like /Volumes/Macintosh SSD.

In the terminal window type:

# /Volumes/Macintosh\ SSD/usr/bin/sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy 
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> delete from kext_policy;

This deletes all kext_policy entries, meaning all Kext's will have to be re-approved the next time you reboot.

By forcing all Kext's to be approved again, you have an opportunity to experiment with why clicking on the Allow button does not work.

I found this long discussion about the issue that contains many possible solutions: github.com Karabiner-Elements issues/1017

The bottom line is that there are many kinds of applications which can interfere with mouse input. Clicking on the Allow button fails because something interfered with the mouse click.

For example

• Screen Sharing
• Magic Perfs
• Steer Mouse
• xGestures
• Slack .. Discord .. IntelliJ
• ..etc..

In other words there's a whole lotta things we might install that is about improving our experience of Mac OS X, and which could be mucking with mouse clicks.

In my case the definitive change happened after exiting Google Chrome. With Chrome running clicking on the Allow button did not work, and as soon as I made Chrome quit clicking on the Allow button started to work.

At that point, with Chrome shut down, I was able to use the Allow button as designed to approve all the Kext's, and then the iShowU device showed up in the Sound preferences as designed.

The discussion does talk about ways to use keyboard navigation to get keyboard focus on the Allow button - at which point it's possible to hit the Spacebar to trigger the button. I did not explore this but it is worth a try.

References

This has a nice background :- plugable.com

Namely, the Gatekeeper added in Mac OS X 10.7 had some changes in macOS High Sierra (10.13) that tightened down the process of installing Kext's. It also unfortunately contributed to the problems outlined on this page.

Official documentation from Apple: developer.apple.com technotes/tn2459

Long list of possible culprits preventing the Allow button to work: github.com Karabiner-Elements issues/1017