The crash screen and its stop codes
What MSL shows when it cannot carry on, and what each code means.
On this page 5 sections
Most things that go wrong in MSL get a sentence and a way out. The crash screen is for the ones that do not: MSL has stopped, and carrying on would mean pretending.
The picture on it is a joke. The panel beside it is not - it carries the code, which part of MSL the failure was about, which part noticed, when, and what was actually measured. That panel is what you quote; Copy report puts all of it on the clipboard, with the observer's own record of the minutes beforehand when the observer is what raised it.
Every stop carries a code - a number like 0x00000010 and a name like SERVICE_CANNOT_LISTEN. The number never changes meaning, so it is worth quoting in a bug report or searching for.
Who raises one#
| Raised by | |
|---|---|
| MSL, about itself | A condition MSL detects where it happens and cannot continue past. 0x10-0x13. |
| MSL's observer | A separate program, mslod, that watches MSL from outside and reports a state MSL cannot get itself out of. 0x20 upwards. See MSL's observer. |
| Nothing | A signal or an unhandled error. 0x01-0x06, and they carry no advice on purpose. |
Codes MSL raises about itself#
0x00000010 SERVICE_CANNOT_LISTEN#
MSL's background service could not open the socket everything else talks to it on, so nothing can reach it. Another copy may already be running. Quit MSL and open it again; failing that, restart the Mac.
0x00000011 SIGNING_KEY_UNREADABLE#
The key MSL signs your instances with is there and cannot be read. Check that /Users/Shared/MSL and the machine-key file inside it still belong to you.
0x00000012 KEY_STORE_UNPROTECTED#
This Mac is managed, but the folder holding the administrator's keys can be written by other accounts, so signed policies no longer verify. An administrator repairs it - see How strong a policy is.
0x00000013 VIRTUALIZATION_REFUSED#
macOS will not let this copy of MSL's service create a virtual machine, so no instance can start. Install MSL from its package rather than copying the files in: the permission is part of the signature and does not survive a plain copy.
Codes MSL's observer raises#
These come from mslod, which is not part of MSL and does not depend on it. Each one is a state MSL has been in for minutes, not a moment of trouble - a single crash that the service recovered from is recorded and never shown. See MSL's observer for how it decides.
0x00000020 SERVICE_WILL_NOT_STAY_UP#
The background service has crashed and restarted several times in a few minutes and never answered anything in between. Quit MSL and open it again - that reinstalls the service from the app. If it keeps happening, the crash report named mslhd in Console's Crash Reports says why, and the report panel quotes the exception type it found.
0x00000021 SERVICE_STOPPED_ANSWERING#
The service is running and accepting connections but has stopped replying to them, so anything that asks it something waits forever instead of being told no. Restart it:
launchctl kickstart -k gui/$(id -u)/com.msl.mslhdYour instances keep their disks, and anything that was running comes back. If it wedges again, restart the Mac before using MSL for anything you care about.
0x00000022 SERVICE_IS_NOT_INSTALLED#
The program MSL runs everything through is missing from where MSL installs it, so nothing can start - most likely an install or update that stopped part-way. Open MSL once: the app reinstalls its own command-line programs every launch. If MSL will not open either, install it again from its package; your instances and their disks are untouched by that.
0x00000023 STATE_DIRECTORY_UNUSABLE#
MSL cannot use the folder it keeps your instances, accounts and settings in, so instances may appear to have vanished. Nothing has been deleted. Check that ~/Library/Application Support/MSL still belongs to you, is readable and writable, and that its disk is not full. Do not delete anything in there - it is where your instances live.
Codes nothing understands#
These mean MSL fell over in a way it did not anticipate. They carry no advice, deliberately: inventing a next step for something MSL cannot explain would be worse than admitting it. They name no subsystem either, for the same reason.
| Code | |
|---|---|
0x00000001 WENT_SOMEWHERE_IT_SHOULDNT | Memory that was not MSL's own |
0x00000002 BUS_TOOK_A_WRONG_TURN | Memory the processor could not give it |
0x00000003 INSTRUCTION_MAKES_NO_SENSE | Something that is not an instruction |
0x00000004 MATHS_HAPPENED | Arithmetic with no usable answer |
0x00000005 GAVE_UP_ON_ITSELF | A check inside MSL that it could not carry on past |
0x00000006 TRIPPED_OVER_A_TRAP | A trap left for a debugger |
An uncaught error shows as UNCAUGHT_ and the error's own name instead of a number.
What MSL does not trade away#
macOS writes its own crash report, with a backtrace, and that file is the thing that actually makes a crash like this fixable. So MSL shows the screen and then lets the process die exactly as it would have. Nothing is given up for the window.
You will find that report in Console ▸ Crash Reports, named after the part that stopped - mslhd, MSLApp, MSLFiles or msl.