OSDev.org

how do i implement a crash screen?

Decide what a crash is and if its conditions are met, display the crash screen.

Added BSOD to our wiki. Crash screen seems to be very popular topic, and I put some pointers how to implement it.

Cheers,
bzt

Your comments on OS X in that article are extremely misleading. It is true that a crash does not provide a mostly useless screen, but on restarting you are presented with an extremely detailed report that can be forwarded to Apple if appropriate. Far from providing no information, as you imply, it provides information in a far more useful form than Windows does.

bzt wrote:Added BSOD to our wiki. Crash screen seems to be very popular topic, and I put some pointers how to implement it.

Cheers,
bzt

There is a small detail that's wrong. I don't know how to edit the wiki. So I write it here.
The "Guru meditation" was for another computer connected (via serial line? don't know) to the Amiga and taking over the control of the Amiga.

Greetings
Peter

PeterX wrote:There is a small detail that's wrong. I don't know how to edit the wiki. So I write it here.
The "Guru meditation" was for another computer connected (via serial line? don't know) to the Amiga and taking over the control of the Amiga.

I only used an Amiga 500 a handful of times - I was working in a WaldenSoft store (a short-lived Waldenbooks offshoot) in 1989, and for some reason they were selling A500s (even though they generally didn't carry hardware, and mostly stocked books and software for PCs) so we had one as a display model - but I can assure you that 'Guru Meditation' was the crash screen for AmigaOS at that time. The Wicked-Pedo page for 'Guru Meditation' backs my faulty memory up on this, and even has a GIF of the original error screen:



Since most Amiga models had no hardware memory protection (and the OS didn't support it at first when it did come around with the 68030 and 68040 models), process protection was entirely in software - a buggy process could scribble on any part of memory, and more than a few would.

Though my understanding at the time was that the reason it was called that wasn't because you would need an expert (t wasn't that serious a problem, you just needed to reboot), but because the computer was unresponsive, like a master yogi in a deep meditation.

It is possible that some Amiga version of a serial-link program - a port of PClink, perhaps - re-used the term for a system being remotely accessed where the local I/O was being disabled, but I am not aware of this being the case. I find it a bit unlikely, since (unlike most other small computer operating systems of the day) Amiga Exec was a fully preemptive-multitasking microkernel from the outset, and so wouldn't usually have needed to disable local user interaction while doing other things.

EDIT: OK, I think I see where the confusion comes from. According the 'Guru Meditation' page, there was a utility called ROMwhack built into the ROM version of Kickstart, which allowed a developer to connect a serial line debugger to the OS when a Guru Meditation occurred. This could be accessed by a right click, whereas a left click would initiate a reboot. Since few actual users had the debugging tools, the error message only mentions the latter option.

it provides information in a far more useful form than Windows does.

on a bugcheck, Windows takes a dump, what a more useful form could be?!!

memory dump, of course.

A text file that contains all the debugging information, rather than a dump file that needs extra tools installed to read it.

Whatever OS X provides a lot of debugging information. This wiki page implies otherwise.

bzt, thanks for the Wiki update.

I wanted to place emphasis on one of the lines you added.

bzt wrote:This function must be dependency-free, and must not rely on other parts of your kernel. It must be self-contained, so that it can display the screen regardless which parts of your OS failed.

For a Legacy BIOS or early EFI machines, where the video hardware still supports VGA access via memory address 0xB8000, a BSOD is fairly easy. Gather the information you wish to display and simply write 16-bit words to the video screen memory.

For modern machines that no longer have this Legacy hardware, it is a bit more difficult, in fact quite a bit more difficult.
1) You have to rely upon the fact that the place you stored the Frame Buffer address is still intact, or some how retrieve it again.
2) You have to rely upon the fact that your basic system font is still intact, or you have to create one on the fly.
3) You have to rely upon the fact that your font render code is still intact, or again, you have to create one on the fly.

A good system will hopefully never crash, but must anticipate a crash. My suggestion would be to choose an area below the 1 Meg mark, an area that once you initialize (as near to the boot process as possible), you will nearly never access again. It should be away from 0x00000000 so that NULL pointers won't access it, though still remain in an area where you won't miss the memory it occupies. Also identity map it 1:1 so that you are not relying on the paging system either.

Then--again as soon as possible after boot--initialize this memory with such information listed above, a simple font and font rendering function, or better yet, actual bitmaps of the characters that you may use. Save things such as the screen's frame buffer address, pixel depth, etc., remembering to update this if the user every changes the resolution. Create the crash code *before* you have a crash. This way it is a simple task, and as bzt stated, doesn't use any current dependency other than what is already in place anticipating the crash.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

Schol-R-LEA wrote: Since most Amiga models had no hardware memory protection (and the OS didn't support it at first when it did come around with the 68030 and 68040 models), process protection was entirely in software - a buggy process could scribble on any part of memory, and more than a few would.

This touches on an assertion that I've always found suspect: Hardcore Amiga fans seem to like to make a point of the fact that the OS was pre-emptively multitasked before any other microcomputer OS was. While technically, yes, any program could be preempted by the timer interrupt, in my book, you don't get to call yourself preemptively multitasked if anybody who wants to can scribble on the timer interrupt vector

The Sinclair QL, released a year before the Amiga, had pre-emptive multitasking.

(Disclaimer - I am a hard-core Amiga fan.)

I catch all exceptions, I display a message in the system log, indicating which exception was raised and the ID of the task that was active at that time. I stop the active task or I restart it if it's the main task (responsible for the video display)

except when the bug is in the main task, it works pretty well. for now I do not display the status of the processor registers or anything to debug, it's the only (known) thing missing from my system

OK, big derailment time. Maybe we can get back to the topic later, though I suspect enough has been said on that already anyway.

linguofreak wrote:

Schol-R-LEA wrote: Since most Amiga models had no hardware memory protection (and the OS didn't support it at first when it did come around with the 68030 and 68040 models), process protection was entirely in software - a buggy process could scribble on any part of memory, and more than a few would.

This touches on an assertion that I've always found suspect: Hardcore Amiga fans seem to like to make a point of the fact that the OS was pre-emptively multitasked before any other microcomputer OS was.

Which isn't really true, of course; it was simply one of the first to be the primary OS for such a system, and the first to really gain widespread recognition, I suppose.

Aside from the Sinclair QL as mentioned by iansjack, there were a number of microcomputer operating systems which were preemptively multitasking going back to the very earliest days - there was a 1976 article in Dr. Dobbs' Journal (which I'd read in the early 1990s, the library at the university I first went to had all the old DDJ annual reprint collections) about CHAOS, a homebrew timesharing OS for the Altair used by a high school in southern California. I even found a program from 1979 written in BASIC for that system.

Anyway, as for commercial systems, well, OS-9, MP/M, and Microsoft Xenix all came out in 1979-80, among others. While none of them were the default OS for the platforms they ran on, as I understand it OS-9 did eventually become the dominant OS for the Tandy Color Computer, though not until late into the CoCo's product life.

linguofreak wrote:While technically, yes, any program could be preempted by the timer interrupt, in my book, you don't get to call yourself preemptively multitasked if anybody who wants to can scribble on the timer interrupt vector

Well, keep in mind that this applied to almost every small computer - including several minis - prior to 1990 or so, and still applies to many modern microcontrollers as well - a number of RTOSes don't assume the presence of an MMU, and some don't use it even when present. I know that the original QNX could run on an 8088 with no MMU, for example. I imagine some of the embedded developers here could say more on this.

Oh, and the first several versions of UNIX ran on PDP-7 and PDP-11 systems with no MMU, as well, though they were quick to adopt it when the KS-11 add-on came around. The lack of an MMU was one of the 'vital parts' from Multics whose absence led to the operating system's punny name, If I am not mistaken.

IIUC, Minix 2.x still supported running on a bare-bones 8088 XT well into the 1990s. Both the LSI-11 and PC versions of Xinu ran without memory management, too. Hell, pretty much every OS textbook I read in the 1980s and 1990s basically assumed that there was no MMU available, despite MMUs being a key feature in mainframes since the late 1960s.

While hardware memory protection was possible through add-ons even in the early 1980s (usually through an MMU from the chip manufacturer and designed in conjunction with the CPU's development, though infamously the Qua! Machine had a homebrew MMU scheme which Massalin developed herself), these were expensive, tended to have significant performance penalties, and weren't seen as being very useful for systems which rarely loaded more than 64KiB-128KiB of memory.

Indeed, one of the touted advantages of the microkernel design when people like Tannenbaum started really promoting it was that it "didn't need" hardware memory protection, since it was vastly better at both process isolation (due to using message passing for IPC rather than shared memory sections and manually-managed semaphores) and system stability (since a hung driver could be shut down and restarted without affecting the kernel itself).

My point is that, given that most of the various pre-emptive multitasking systems ever written were on systems with no MMU, saying that they weren't pre-emptive multitasking systems at all is a hard sell.

Thanks for the feedback!

@iansjack: the page is about the crash screen, and so is the comment. MacOSX does not display any information on the screen. The note only says that there are other ways to get those information (and yes, MacOSX provides lots of information, just not on the crash screen).

As you can see, there are no details on the screen. Although it says the computer has rebooted, the same screen appears during crash, with just a little bit different text. I was unfortunate to see this for myself a couple of times, however this was the best screenshot I could find.
https://en.wikipedia.org/wiki/File:Crashed_computer.jpg
And this is the other kernel crash, with backtrace and register dump. Note the last "Waiting for remote debugger connection." line. I have never ever seen this myself, this screenshot is from wikipedia.

@PeterX: when Guru Meditation was shown, you had two choices: left click - reboot computer. Right click - start remote debugger interface on serial line (required a full debugger on another machine to connect to). This debugger interface (very similar to gdb-server these days) was built in a ROM not the debugger, just as Schol-R-LEA said.

@BenLunt: thank you! Exactly, maybe my wording is not the best, but I wanted to say that you have to write to the video memory directly, and you should not rely on other parts of your kernel, because kpanic supposed to work regardless. For example you should not map the framebuffer in kpanic because the crash might be caused in your paging routines, meaning you wouldn't be able to display anything. A little clearification might be good, and I think you should add your list and description to the wiki page, because it's great and through.

@Schol-R-LEA: maybe some of this could be added to the "History" section, what do you think? (Considering problems caused by the lack of MMU was one of the most common reasons for BSOD)

Cheers,
bzt

bzt wrote:@PeterX: when Guru Meditation was shown, you had two choices: left click - reboot computer. Right click - start remote debugger interface on serial line (required a full debugger on another machine to connect to). This debugger interface (very similar to gdb-server these days) was built in a ROM not the debugger, just as Schol-R-LEA said.

Just what I said Or I didn't express clearly. Anyway that's what I was trying to say.

Windows probably was the holder of the world record of crash screens. It's name BLUE s.o.d. for a reason: Because the Win crash screen was blue. When I used Windows 95, ANY time a crash could occur. For example in the middle of writing a text.

I don't know if BSOD is an imprtant feature. But perhaps it improves debugging a lot. I'm not sure.

Greetings
Peter