In macOS High Sierra, System Prefs > Security, it says "Some system software was blocked from loading. I see a list there of three developers, and I don't recognize all of them. I'm guessing these are kext files in /L/E or /S/L/E, but how can I identify exactly which kext corresponds to each developer name? I tried grep -rn "Intel Corporation Apps" /System/Library/Extensions but that doesn't find it.enter image description here

EDIT: Adding to this question because it was never fully answered and I have now encountered another stubborn kext I can't remove in Mojave. It appears in Disabled Software but not in System Preferences security pane. enter image description here

I have grepped /L/E and /S/L/E and /Library/StagedExtensions and the only result I find is in /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist

kextutil can't find it so where else can I look?:

# kextutil -b cn.com.bwstor.filesystems.enfs
Can't find extension with identifier cn.com.bwstor.filesystems.enfs
  • 1
    Everyone, please report this defect (the "extension blocked" warning and behavior with no way to find the extension) to Apple: feedbackassistant.apple.com
    – Oscar
    Commented Nov 14, 2020 at 22:39

5 Answers 5


I figured it out. In System Information > Software > Disabled Software, it shows a list of these extensions with their bundle identifier. In my case, that was enough info to understand what the app is, but to locate the actual kext file requires more digging. Example:

grep -r "com.aladdin.kext.aksfridge" /Library/Extensions finds nothing.

grep -r "com.aladdin.kext.aksfridge" /Library/Application Support found it.

I'm not sure if there is a documented list of locations that are allowed to load kexts, but you could grep the whole hard drive for the bundle ID and that would surely find it.

Be prepared to wait as grep -r scours your entire hard drive...

If you find your file is an extension located in: /Library/StagedExtensions/Library/Extensions/

sudo rm -rf will not work, you can only remove it using:

sudo kextcache --clear-staging


I had a similar experience today. I thought it might be of help for you.

"System Preferences > Security & Privacy > General" tab showed me a blocked system software. It mentioned developer 'Jongwoo Choi' which I didn't recognize. What software is this? Where is it installed? After searching the internet regarding these blocked software extensions they appear to be "kernel extensions" or .kext files.

Some more searching taught me this:

  • "System Information > Software > Extensions" shows all the extensions installed on your machine. Give it some time to load, the list might be long.
  • Now, too find the blocked extension by this developer, I ordered the list by "Obtained from". If you have an extension name, you can order by "Extension name" column. Most of the extensions are obtained from Apple so I guess these can be skipped. Also those with "Loaded" value "yes" can be skipped as well since the software is blocked from loading. I then checked each item from "Identified Developer" or "Not Signed".
  • You now should be able to find the developer or company name (that was mentioned in the "System Preferences > Security & Privacy > General" tab list of blocked software) in the details you get for each item in the window below the extensions list. Check the value for "Signed By". For me there was only one entry for that specific developer.
  • Once you found it, the value for "Location" will show you where the .kext file is located. The value for "Bundle ID" might also help to explain what this is about.

Since the kernel extensions wasn't loaded I decided to remove it.

sudo rm -rf path/to/the/kext/file

I then rebooted (not sure if it is needed). "System Preferences > Security & Privacy > General" didn't show me the blocked software message. Hooray!

However, "System Information > Software > Disabled Software" DID still show me one entry of disabled software. I recognised the entry title from the detailed information in the extension list earlier on. It is the one I just removed. For me this was "F3YNT8UCP3 - net.sf.tuntaposx.tap"

Why is it still there while I removed the .kext file? As Elliott mentioned in a comment above, it seems that there is a SQLite db that tracks information about the approval of installed software. Deleting the .kext file does not remove the entry from the database.

How to remove the entry from the db to remove it from the "System Information > Software > Disabled Software" list is described in here on Stack Overflow. The first part of the disabled software entry is the Team ID (F3YNT8UCP3 in my case). You'll need this ID to specify which entry to delete from the SQLite db.

So removing the .kext file should remove the warning in "System Preferences > Security & Privacy > General". Removing the item from the SQLite db should remove the disabled software entry in "System Information > Software > Disabled Software".

  • How do you locate the kext file? I don't see a Location column in the disabled software list.
    – Elliott
    Commented Dec 14, 2020 at 13:43
  • 1
    @Elliott, Location is not a column in the list. But it is available in the detail pane below as soon as you select one entry in the list. By list I mean the "About this Mac > System Report > Software > Extensions" list. Commented Jan 3, 2021 at 17:12

Adding to your own answer, Elliott, you can then feed this bundle ID to kextutil:

sudo kextutil -b "com.hp.kext.hp-fax-io"

Which will then tell all you ever wanted to know about it including the location of the .kext file:

file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/ is in hash exception list, allowing to load
Kext rejected due to system policy: <OSKext 0x7fe302c19730 [0x7fffa5fc38f0]> { URL = "file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/", ID = "com.hp.kext.hp-fax-io" }
Code Signing Failure: not code signed
    Personality CFBundleIdentifier differs from containing kext's (not necessarily a mistake, but rarely done):
        HPF00072 FAX - 2
        HPF00006 FAX - 2

Also it seems you can generally find all those extensions in that directory:

$ ls -la /Library/StagedExtensions/System/Library/Extensions
drwxr-xr-x@ - root 14 Feb  2013 hp_fax_io.kext
drwxr-xr-x@ - root 19 Aug  2013 hp_Inkjet1_io_enabler.kext
drwxr-xr-x@ - root 19 Aug  2013 hp_Inkjet9_io_enabler.kext
drwxr-xr-x@ - root 31 Okt  2014 intelhaxm.kext
drwxr-xr-x@ - root 22 Mai  2012 JMicronATA.kext
drwxr-xr-x@ - root 16 Aug  2012 Pen Tablet.kext
drwxr-xr-x@ - root 23 Jul  2016 SiLabsUSBDriver64.kext
drwxr-xr-x@ - root 23 Jul  2016 Wacom Tablet.kext
  • This is great info, but today I have two kexts listed in Disabled Software that do not appear with kextutil, it says can't find extension with that identifier. I've been grepping the entire disk for over an hour but haven't found anything.
    – Elliott
    Commented Feb 27, 2019 at 4:39
  • 1
    Figured it out! This info is stored in a SQLite database in /private/var/db/SystemPolicyConfiguration and you need to disable SIP to modify it.
    – Elliott
    Commented Feb 27, 2019 at 8:27

I came to this discussion while trying to validate kexts migrated from 10.13 to 10.15 which weren't loading. I seem to have found an explanation and a workaround.

The kexts were valid for 10.15 but hadn't been installed under 10.15, as they arrived with a system migration. I assume the same problem would occur with an OS upgrade. (It goes without saying that I'm deeply disappointed in Apple for not foreseeing this eventuality.)

I came across the following advice regarding installing SATSMART drivers in the FAQ on binaryfruit.com which has some relevance to the question:

How to rebuild macOS kernel extensions/driver cache

When the macOS boots – it saves all currently used kernel extensions (drivers) into a cache for faster booting next time – and if you move things around in “/Library/Extensions/” and “/System/Library/Extensions/” – you won’t see those changes reflected until the caches are rebuilt. Also, due to bugs in some versions of macOS – kext cache becomes outdated or corrupted, especially in the case of system upgrades. Manual kext cache rebuild could fix many troubles with drivers (kernel extensions).

Type in the terminal following commands:

sudo kextcache -i /

sudo kextcache -system-caches

The first command brings up a complete list of kexts that were not loading for a number of reasons - including (but not limited to) Kext rejected due to system policy meaning permission had not been granted in Security & Privacy - along with their locations.

In my experience, kexts blocked for reasons other than needing user approval show up here, even if they don't appear amongst Disabled Software.

Addressing the OPs original question more specifically regarding knowing who the kext developers are, since this may not directly correspond to the software branding, these can be parsed from package inspector apps such as Pacifist and then compared with the kext names output by the terminal command above.

My personal preference is to open an installer package in Suspicious Package, where the developer and their 10 character alphanumeric TeamID are easily readable. For kexts simply awaiting user approval this does, of course, correspond with the TeamID found in Disabled Software, as explained by the OP above. However, not only is this user friendly, it also exposes kexts that won't load for other reasons.

Once the TeamID is known, the kext can safely be approved in Security and Privacy when the blocked kext alert is next shown (eg when installing a different kext).

Not everybody wants to install a new kext in order to approve earlier ones and some sources (such as this MIT knowledge base) advise that a team ID can be granted kext approval via terminal commands in Recovery Mode, but I can't personally verify whether this works in a specific OS.

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – nohillside
    Commented Jun 24, 2022 at 11:32
  • Hi nohillside, could you explain what's unclear here please? AFAIK I've set out all the steps I took, posted all the links I used, and included all the information I had and used to cmplete this process. I'm happy to edit and clarify if you can give me a pointer as to what comes across as unclear or incomplete. Thanks.
    – Macaroon
    Commented Mar 5, 2023 at 17:51
  • Longer edit: Hi nohillside, could you clarify what's unclear in my answer please? AFAIK I've set out all the steps I took, posted all the links I used, and included all the information I had at the time. I've shared advice gathered from elsehwere (links provided) and the names of a couple of apps to help identify the TeamID of suspected blocked kexts, which directly answers the OP's original question: "How can I identify exactly which kext corresponds to each developer name?" I'm happy to edit and clarify if you can give me a pointer as to what comes across as unclear or incomplete. Thanks.
    – Macaroon
    Commented Mar 5, 2023 at 17:57
  • It has been a while, and you edited the answer after I added my comment. But if I remember correctly, I was struggling to find the answer to "how can I identify exactly which kext corresponds to each developer name?" in your post. Not sure this is still the case though.
    – nohillside
    Commented Mar 6, 2023 at 15:08

I don’t have a complete answer, but there are amazing reverse engineering efforts and information sharing that might get you the final piece or a foothold enough to roll your own.

Richard Purves has done amazing work to cover “kextpocalypse” and scripting and most major MDM vendors have specific examples how to push white lists and deal with this user approved kernel extensions.

Also, be aware the behavior isn’t fully set as Apple is refining and changing how this works each release (lately) so YMMV more than usual.

Michael Lynn also is way above and beyond what I’d expect from a paid consultant putting out powerful scripts and documenting them expertly.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .