is there the way to avoid the panic file generation?

Hello,


I am wondering if there's kind of way that can be used to avoid the generation of the panic file...

The backgroud is we develop a kext and it panics on some machines, but there's no any panic file created in the /Library/Logs/DiagnosticReports folder, interesting we do see the pop up window saying "Your computer encounters issue... More details or Ignore" like this, the panic content will display in the text area of the popup, but no panic file created

Replies

Kernel extensions are deprecated.

Yeah, we know that. But the fact is the kext still can be loaded for the latest release. The problem is happened on a machine with macos 10.14.6 with below message when panic occurs:


"build" : "Bridge OS 4.5 (17P5290)",

"crashReporterKey" : "c0dec0dec0dec0dec0dec0dec0dec0dec0de0001",

"date" : "2020-06-16 03:38:13.18 +0000",

"incident" : "B3549D58-E9CD-4D71-9478-D3AD259C8121",

"kernel" : "Darwin Kernel Version 19.5.0: Thu Apr 30 23:53:45 PDT 2020; root:xnu-6153.120.31~33\/RELEASE_ARM64_T8010",

Yeah, we know that.

To clarify, not all KEXTs are deprecated. See Deprecated Kernel Extensions and System Extension Alternatives for the specifics.

I’m confused by your overall goal:

  • Are you trying to suppress the panic log being created?

  • Or force it to be created?

  • Or work out why it’s sometimes created and sometimes isn’t?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

That's a bridge panic. I doubt it is related to your extension.
Bridge panics often don't generate a report. In theory, the system is supposed to save the panic report in NVRAM and then record it after restarting. But since you are dealing with the embedded version of iOS in a Mac that deals with that kind of low-level behaviour, you may not get the report. See if it is still in NVRAM. You might need to try some 3rd party tools, possibly even some 3rd party OS tools. Some NVRAM values are only accessible if you are running Linux.


However, I'm not sure it is worth the effort. Can you positively confirm that your extension is causing the panic? Can you reproduce the panic on demand? Does the panic occur on any individual machine of a certain model? Do you have any 3rd party hardware connected?

Thanks for opening this thread. Can you reproduce the panic you're trying to "avoid" generating and file a bug with a sysdiagnose after doing so? This will allow us to better understand what's going on so we can help here.

Detailed instructions on how to file a bug are available here. Please post your bug number here for the record.