Crash an application on NSException

Peter Steinberger on Twitter, just posted a quick tip that reverts the current behavior of silent failures under recent versions of macOS.

https://twitter.com/steipete/status/1223228727477272577

Use NSUserDefaults to set the value of “NSApplicationCrashOnExceptions” to true and your application will crash like it used to. Thus generating a crash report, showing you what went wrong and where. Opposed to silent failures, which are hard to find in console.

He also posted this one back in October 2019, but I didn’t see it.
https://twitter.com/steipete/status/1187770905767927809

Given that I have an MBS license, I put the following into the Open event of my app:

#If TargetMacOS Var u As NSUserDefaultsMBS = NSUserDefaultsMBS.standardUserDefaults u.setBoolValue("NSApplicationCrashOnExceptions", True) #EndIf
This seemed to update the auto-created file located at /Users/scott/Library/Preferences/com.mycompany.myapp.plist which now looks like the following:

I guess as long as that entry is in the plist file, the OS takes care of the rest?

You always have the greatest pointers Sam, thanks again!

1 Like

Glad I could help.

If you’re on twitter; make sure you hit up @steipete and let him know it helped. I wouldn’t have found this tip without him. I’d started trying to get into the depths of handling NSExceptions myself, simply so that I was aware when, where and what was happening.

FYI - Scott
You can just add to the apps plist at build time by creating a text file named info.plist and then dragging it into the project
It lets you add key / value pairs to your build apps default plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
    <key>NSApplicationCrashOnExceptions</key><true/>
</dict>
</plist>

Adding the Info.plist file for macOS apps is one of the best kept, documented secrets of Xojo :smiley:

http://docs.xojo.com/UserGuide:Using_a_plist

http://docs.xojo.com/Changes_2014r2
and yer welcome :stuck_out_tongue:

[quote=475025:@Norman Palardy]You can just add to the apps plist at build time by creating a text file named info.plist and then dragging it into the project
It lets you add key / value pairs to your build apps default plist[/quote]
Thank you Norman for the link, I knew there was a mechanism for including a plist in a project, but hadn’t had a chance to explore it much yet.

With some of the things I’d like to do, I know I’ll have to dig into this further eventually.

I smell a blog post …

[quote=475025:@Norman Palardy]You can just add to the apps plist at build time by creating a text file named info.plist and then dragging it into the project
It lets you add key / value pairs to your build apps default plist[/quote]
Does it work if added to the application plist?

The usage described by @steipete is to set it to the defaults. Sadly it’s undocumented, so there’s no official word from Apple on this.

Now I’ll have to try that and see if a per app setting like this works as expected as it would be different from the user defaults

That just about sums development for Apple up in one sentence. >:(

1 Like

So, if NSApplicationCrashOnExceptions is false, does the app continue limping on silently or does it crash with no report?

I don’t know; lemme check the documentation… Oh that’s right, it’s not documented.

I can’t tell you how happy I was when I read this tip. I had gotten to a point where I started to accept that 10.14 was just a fundamentally broken OS. I’d take me days to track down which API was breaking functionality, nothing was written to the log, so I just assumed that it’s broken.

Once I saw this tip and now use it all my apps, I started to test things that I thought were broken. Sure they’d changed in behavior, but with this, they’d crash. The crash log would then display the API that was causing the exception, and most importantly WHY!

I’ve pretty much been able to get everything working again.

This has to be one of the most ridiculous changes made to the macOS yet, even people I’d consider my peers have been struggling with apps suddenly going limp and no indication why. I can only assume it was done, to make it seem like newer OS version were more stable, because hey apps don’t crash any more.

A while ago I had found this lovely bug here: feedback://showreport?report_id=58879 (hard crash when making a date). At the customer it was hard to track down because the app didn’t crash on Catalina. The non-crash behaviour is really really clever. The bug isn’t even reviewed, yet. Sigh…

I wonder if this would work with kexts. I have a driver that is running two of my guys bonkers. The driver works in Big Sur IF the system was upgraded from 10.14 or 10.15. But, if it’s a clean install on a new 11.x system, the launch fails with no kernel or crash output.

Oh man…

It is worth a shot, just make sure that you set the default before you do anything else.

@Tim_Jones
Have you tried the CrashReporterPrefs app that’s in the Xcode additional tools?

1 Like

Doesn’t appear to work with kexts.

Not fully understanding how I fix it?
I’m not currently using NSUserDefaults because I didn’t think IOSKit worked on the latest Xojo

If you use the Ohanaware App Kit, this is set for you when you call OAK2020.init( true ).

Otherwise if you use one of the other application kits, you should be able to translate the following line.

NSUserDefaultsSetBoolForKey( NSUserDefaultsStandard, true, "NSApplicationCrashOnExceptions" )

1 Like
Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.