A signed DriverKit extension fails OSSystemExtensionRequest activation on macOS 26.4.1. The user-facing error is OSSystemExtensionErrorDomain code 4 ("Extension not found in App bundle") — but the dext is in the bundle, the identifier matches, and sysextd confirms it received the request:
sysextd: [com.apple.sx:XPC] client activation request for com.arqitekta.bluefield.rshim.driver sysextd: attempting to realize extension with identifier com.arqitekta.bluefield.rshim.driver
…and then nothing further. systemextensionsctl list reports 0 extensions.
Question: Which log subsystem/category surfaces the kernel-side reason that sysextd aborts after "attempting to realize"? com.apple.sx only shows the request was accepted; whatever vetoes the realize step isn't in that subsystem (or isn't at info/debug level). Is there a separate predicate for the kernelmanagerd / dext-loading path I should be capturing?
Environment:
- macOS 26.4.1 (25E253), Apple Silicon Mac Studio
- Xcode 26.2 (17C52), DriverKit SDK 25.2
- SIP disabled, systemextensionsctl developer on
- Apple Developer Program, signed "Apple Development: …"
- DriverKit entitlement request 264CFJJU36 approved; profile includes com.apple.developer.driverkit, allow-any-userclient-access,
transport.pci
Already verified:
- Dext at Contents/Library/SystemExtensions/RshimDriver.dext
- CFBundleIdentifier matches the request, CFBundlePackageType=DEXT
- codesign --verify --deep --strict passes on app + dext
- embedded.provisionprofile parses, contains the expected entitlements
- Three IOKitPersonalities (BF2 / BF2-alt / BF3) using Apple's placeholder IOPCIPrimaryMatch
- Installer app entitled with com.apple.developer.system-extension.install only
- spctl -a -vv on the dext reports "rejected" — expected for development signing, should be bypassed under developer mode
Minimal repro: https://github.com/jfabienke/bluefield-macos-toolkit/tree/dev-stub-entitlements/rshim-dext — build.sh produces the failing app
- dext. Captured artefacts (build output, embedded profile dump, signing report, repro shell script) under rshim-dext/dts-artifacts/.
Looking for either (a) the right log show predicate to find the actual refusal reason, or (b) an environmental requirement on macOS 26 I'm missing.
Question: Which log subsystem/category surfaces the kernel-side reason that sysextd aborts after "attempting to realize"?
It actually told you the exact answer here, it just didn't sound like it was the real answer:
"Extension not found in App bundle"
There's another forum thread about this here, but the problem is your DEXT's name:
.../RshimDriver.dext
From the System Extensions Overview:
To successfully activate your extension, you must adhere to the following rules:
- The extension must match your bundle identifier, excluding the file extension. For example, a DriverKit extension with bundle identifier com.example.usbdriver must use the filename com.example.usbdriver.dext. Similarly, a NetworkExtension extension with bundle identifier com.example.networkextension must use the filename com.example.networkextension.systemextension.
whatever vetoes the realize step isn't in that subsystem (or isn't at info/debug level). Is there a separate predicate for the kernelmanagerd / dext-loading path I should be capturing?
No. sysextd is what failed the load and it didn't log additional info because the error it passed back contained the "full" explanation.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
