Open App Safe Mode Mac

  1. Outlook Safe Mode Mac Os
  2. Boot Mac In Safe Mode

App needs a lot of work before it’s truly useful I thankfully didn’t buy the device expecting this app to be fantastic, since as of this writing it has 1.7 stars. I can connect to the device consistently, and more or less see that it’s up to temperature, however no matter what I do the safe mode overlay appears for me.

Use the setting in the log out or restart dialog

When you log out of your Mac or restart it, deselect ”Reopen windows when logging back in” when prompted.

Or start up in safe mode, then restart normally. This doesn't change the setting, but your Mac forgets any windows that were open the last time you logged out or restarted.

If you deselect this setting and an app continues to open automatically:

  • The app might be a login item. You can add or remove login items in Users & Groups preferences.
  • The app might have installed its own startup software. Often this is controlled by a setting within the app. Check the app's preferences or documentation, or contact the app's developer.

Outlook Safe Mode Mac Os

Use the setting in General preferences

To prevent apps from remembering the windows they had open, choose Apple menu  > System Preferences, click General, then select ”Close windows when quitting an app.”

Or press and hold the Shift key while opening an app. This doesn't change the setting, but the app forgets any windows that were open the last time you quit the app.

If these steps don't work for an app, the app might have its own setting for reopening windows. Check the app's preferences or documentation, or contact the app's developer.

A few weeks ago, I considered here whether starting up in Safe Mode (with the Shift ket held) checks and repairs disks, as it has done in the past. I concluded then that macOS Catalina no longer does that. This article looks at what Catalina’s Safe Mode actually does.

Apple’s current support page detailing Safe Booting was written over two years ago, and clearly hasn’t been updated for 10.15 yet. According to that, entering Safe Mode at startup does three things:

  1. it verifies the boot disk and, if there are any directory issues with it, it attempts its repair;
  2. it blocks the loading of many kernel extensions, startup and login items, and user-installed fonts;
  3. it deletes font caches, the kernel cache, and other system caches.

The second of those limits its usefulness, as some of the blocked items prevent some sub-systems from working normally. If you’re trying to isolate a problem which affects one of those sub-systems, Safe Mode won’t help.

I’ve now performed Safe Boots on a MacBook Pro 2017 (without T2 chip) running both 10.15 and 10.15.1, and conclude that no useful check of the integrity of storage is performed any more, have compiled a list of kernel extensions which aren’t loaded in Safe Mode, and looked at some of the ‘caches’ which it rebuilds. Let me step you through some typical log entries from starting up in Safe Mode. As usual, times are given in decimal seconds, in local time UTC+0100.

Open App Safe Mode Mac

As with all startups, the log entries open with two characteristic waypoints:
3.000000 system boot: [UUID]
3.000000 log class: in-memory begins

Note that the UUID/GUID given here appears to be unique to that startup, rather than any for that machine.

The first indication of Safe Booting appears very early in the log. I’ve always been uncertain how long to hold the Shift key for. In this case, less than a second from initiating the startup should have been fine.
3.054764 kernel SAFE BOOT DETECTED - only valid OSBundleRequired kexts will be loaded.

In 10.15, you will then see scattered entries referring to kernel extensions which haven’t been loaded, such as
3.352849 Kext com.apple.vecLib.kext is not loadable during safe boot; omitting its personalities.
In 10.15.1, there’s now a full listing by subsystem of all the kexts which aren’t loaded, which I reproduce at the end of this article.

Almost exactly one second after the initial log entry, the new Catalina Volume Group is prepared and mounted (just as in a regular startup):
4.080006 ROSV: apfs mounted RO and is the system volume of a volume group and mounted as the root fs: creating the shadow fs_root
4.080063 apfs_vfsop_mount:1463: mounted volume: Macintosh HD
4.081282 attempting kernel mount for data volume...
4.084126 attempting kernel mount for vm volume...

There are no log entries which report that fsck_apfs is being run, nor of any results of that. This is almost unnecessary anyway: compare the time taken for Safe Boot in Mojave with that in Catalina, particularly if you have any snapshots which need to be checked. Safe Booting in Catalina – on my system at least – takes little longer than a regular startup. If you experience any different, please let me know.

One major task which appears in Safe Boots is a thorough rebuild of OpenDirectory databases. This is heralded by the log entry:
6.504643 opendirectoryd Safe boot is enabled

Every startup is followed by a quick clean-up of temporary files, which is performed by the Directory Helper:
6.516512 dirhelper Cleaning T/ older than 3 days
6.516518 dirhelper Cleaning TemporaryItems older than 3 days

Another new and important service which takes note of the Safe Boot is Endpoint Security:
6.517115 endpointsecurityd Safe Boot mode detected
As this subsystem is so new, and little-used still, the implications of this aren’t clear yet.

Shortly after that, the OpenDirectory rebuild swings into action, with a great many log entries such as
6.816245 opendirectoryd PlistFile Database '/private/var/db/dslocal/nodes/Default/sqlindex' passed integrity check
6.816455 opendirectoryd PlistFile Database closing '/private/var/db/dslocal/nodes/Default/sqlindex'
6.816568 opendirectoryd PlistFile Database removed '/private/var/db/dslocal/nodes/Default/sqlindex' along with journal file
6.823589 opendirectoryd PlistFile re-indexing '<private>' with type 'computers'
6.833248 opendirectoryd PlistFile re-indexing '<private>' with type 'users'

repeated many times, progressing through sharepoints, config and groups.

Many of the caches which are cleared as user-specific, so don’t appear until after login. That process is marked by distinctive entries such as
loginwindow main | Login Window Application Started
loginwindow -[SessionStateMonitor setLoginState:] | ************* login state: InitialStartup

Boot Mac In Safe Mode

Unfortunately, once user processes start up, finding anything among them to indicate specific caches being cleared is like looking for a needle in a haystack. When I have plenty of time (!), and fancy browsing the 58 MB of log entries again, I may revisit this. But I have no reason to doubt Apple’s claim that various user caches are cleared.

To return to Apple’s original list of what happens in Safe Mode, as far as Catalina goes:

  1. if any verification of the boot Volume Group does take place (which doesn’t appear to be the case), it’s performed in secret;
  2. it blocks the loading of many kernel extensions (listed below), startup and login items, and user-installed fonts;
  3. it deletes font caches, the kernel cache (which I think is started afresh on the VM volume anyway), and other system caches;
  4. it rebuilds OpenDirectory databases.

Appendix: List of Kernel Extensions Which Aren’t Loaded in Safe Mode (10.15, 10.15.1)

AGDCPluginDisplayMetrics.kext
AppleCameraInterface.kext – this means a built-in camera can’t be used
AppleFIVRDriver.kext
AppleGFXHDA.kext
AppleHDA.kext
AppleHDAController.kext
AppleHDAHardwareConfigDriver.kext
AppleHV.kext
AppleIntelKBLGraphics.kext
AppleIntelSlowAdaptiveClocking.kext
ApplePlatformEnabler.kext
AppleSMCLMU.kext
AppleSSE.kext
AppleThunderboltEDMService.kext – these may prevent use of some Thunderbolt devices
AppleThunderboltIP.kext
AppleUpstreamUserClient.kext
AudioAUUC.kext
DspFuncLib.kext
eficheck.kext – this means that firmware integrity checks aren’t performed on non-T2 models
fileutil.kext
IOAudioFamily.kext
IOAVBFamily.kext
IOBluetoothSerialManager.kext
IOgPTPPlugin.kext
IOHDAFamily.kext
IOUserEthernet.kext
msdosfs.kext – this makes the Mac unable to access MS-DOS file systems
nke.rvi.kext
OSvKernDSPLib.kext
pmtelemetry.kext
vecLib.kext
and user-installed kernel extensions. Apple hasn’t yet explained what will happen with loading of its new ‘SEXTs’, but I suspect that they too will be blocked.