Crash Debugger

This is a sub-page of The Legend of Zelda: Majora's Mask.

Majora's Mask contains a crash debugger just like Ocarina of Time does. It was used by the game developers to diagnose crashes that occur, and is expanded a lot compared to OoT's crash debugger.

It is present in all N64 versions of the game. To trigger it, you first need to crash the game in some way, either by using one of the game's various glitches or by Crooked Cartridge if you're desperate enough to damage the cart. Once a crash is triggered, the game will alternate between the last two framebuffers before showing the last "blended" frame (used for blur effects like the title screen cutscene), and displaying a color bar which indicates the type of crash that occurs. Now, you need to type in the following button combination:

D-Pad Left + C-Right + L + R + Start

That's it. No finger breaking is necessary, unlike in OoT.

The crash debugger will usually execute correctly on emulators, but HLE emulators will not display the crash screen because they utilize an external framebuffer to allow for upscaling. Due to the differences between the N64 and the GCN the crash debugger does not work on the GCN version of MM.

Register Dump#

Both OoT and MM use the same first screen. This is the most important one, as it provides the most basic information concerning the status of the system at the time of the crash. Most (if not all) of the information shown comes from a register, either on the System Control Processor (top), the main CPU, or the Floating-Point Unit (bottom).

Stack Trace 1#

This screen displays the call stack before the exception occurred. The first row shows the current Stack Pointer (SP) and Program Counter (PC) at the time of the crash, while subsequent rows represent different function calls that lead to the faulting code. The Virtual PC (VPC) column shows the virtual address conversion of the PC. Virtual addresses uniquely identify portions of code that can be dynamically allocated (actors for instance).

In general, the smaller the SP value, the larger the Stack (i.e. more stuff that's on it). This may not always be the case true however, as the SP has been observed to jump from $801xxxxx to $807xxxxx. This probably happened because the Stack was getting too big for where it was, so the new data was placed on the Expansion Pak where it could fit.

The number of lines on this screen vary, for unknown reasons.

Thread hangup screen#

This screen is uncommon but can appear. For example, it can appear after crashing in the defective Snowhead Temple with Epona. The screen shows a second thread ID (usually 2, for some reason), as well as the source code filename responsible (such as "../z_std_dma.c").

Actor List (Instances)#

Lists the starting point of every actor instance loaded in memory at the time. Interestingly, the actor number (to the right of the start address) is listed in hexadecimal, rather than decimal as was done on the next screen and in OoT.

Actor List (Code Files)#

Lists the start and end points of the actor overlay (code) files currently loaded. The right column is the number of instances of that actor loaded.

Screenshots#

At this point, the debugger takes a moment to show two screenshots from the moments leading up to the crash. The last two frames drawn to the screen are displayed, with the most recent coming last. The two are often the same image, with maybe a slight difference in one of the icons on the screen.

Version Info#

No debugger is complete without this, it seems.

During development, there are typically several different builds, so having a specific version dated is helpful. Also on the screen is the text "SP_STATUS", which may be related to the stack.

Scheduling Info#

This screen isn't well understood. There are always two lines, GRAPH and AUDIO. However, sometimes another block of information appears, called RSPTask. The odd thing about this last bit of information is that not only doesn't always appear, but sometimes decides to appear randomly during the same debug session!

This screen probably relates to thread/task scheduling (GRAPH(ics) and AUDIO being two task names).

Dump#

This is the generalized version of the two dump screens of the OoT debugger. Here, you can examine anything that's stored in RAM. Here are the controls for the dump screen:

• Up, Down = scroll one line, or $10 (16 bytes)
• A + Up, Down = scroll a distance of $100 (256 bytes)
• B + Up, Down = scroll a distance of $1000 (4096 bytes, or 4KB)
• A + B + Up, Down = scroll a distance of $10000 (65536 bytes, or 64KB)
• C Down = Jump to the Stack (stack dump)
• C Up = Jump to the section of code that caused the crash (PC dump)
• C Left, C Right = scroll to $80000000 (start of RAM)
• START = exit the Dump screen

Stack Trace 2#

Nearly identical to the first Stack Trace, albeit with a differing final column.

The third column almost always reads "????????." However, the ? marks are occasionally be replaced with a pointer value in the range $8080xxxx, outside of the physical RAM space.

CONGRATURATIONS#

A message likely intended for QA testers. Of note is the "congraturations" typo.

It should be noted that this appears in Doubutsu no Mori's crash handler, complete with typo.