A common error is to start the rmon thread at the same priority as the boot thread. Rmon then immediately goes to sleep and locks up the system. The recommended way for starting the system is to create an idle thread in the boot procedure at a high priority. From the idle thread start all the other application threads, then lower the priority to zero and loop forever to become the idle thread. Note that the rmon thread is not needed for printfs. See the osSyncPrintf() man page.
During the development of your game, you may unintentionally encounter various CPU exceptions (or faults) such as TLB miss, address error, or divide-by-zero. Currently, the system fault handler saves the context of the faulted thread, stops the faulted thread from execution, sends a message to any thread registered for the OS_EVENT_FAULT event, and dispatches the next runnable thread from the system execution queue. If rmon is running, it would register for the OS_EVENT_FAULT event, receive the message from the exception handler, stop all user threads (except the idle thread), and send the faulted thread context to the host. If gload is running on the host, it would receive the faulted thread context and print its content to the screen. If gvd is running on the host, it would receive the fault notification and point you to where the fault occurred. If rmon is not running on the target, you probably experience strange behavior (i.e. hang) in your game since the faulted thread can no longer run.
If you want to catch the OS_EVENT_FAULT event (instead of using rmon), you can use two internal OS functions to find the faulted thread and handle the exception yourself.
_osGetCurrFaultedThread() _osGetNextFaultedThread()
Please refer to the "N64 Online Function Reference Manual (man pages) for more information.