Mac OS 9 Power Management Error Logs and Diagnostics

During the Mac OS 9 era, the operating system lacked the centralized, automated logging daemons found in modern Unix-based systems like macOS. When power management failures occurred—such as sleep-to-wake crashes, Power Management Unit (PMU) timing faults, or Energy Saver hangs—Mac OS 9 rarely wrote persistent text logs to the disk automatically. Instead, technicians and developers relied on low-level exception handlers, hardware error codes, interactive debuggers like MacsBug, and specific Power Manager return codes to identify and diagnose the failure.

System Bomb Dialogs and Power Manager Error Codes

When a power management failure caused the operating system to crash immediately, Mac OS 9 typically displayed a standard system error alert, colloquially known as the "bomb box." These alerts presented low-level system error IDs representing the specific CPU exception triggered when the system attempted to enter or resume from sleep. The most frequent errors included:

  • Error Type 1 (Bus Error): Often triggered when hardware devices, PCI cards, or drivers failed to restore power to their respective buses before the CPU requested access.
  • Error Type 10 (Line Unimplemented Trap): Occurred when an invalid or corrupt Power Management toolbox call was executed.
  • Error Type 11 (Hardware Exception): Common on PowerPC architecture when memory addresses mapped to peripheral power controllers became unavailable during a power transition.

If an application or system extension intercepted the issue gracefully through the system's Power Manager API, it received distinct numeric return codes rather than crashing the machine. These negative system result codes fell into the -13000 to -13099 range:

  • pmBusyErr (-13000): The Power Management Unit was busy executing another hardware command.
  • pmAckPrsntErr (-13001): The PMU failed to acknowledge an instruction sequence.
  • pmSendAgntErr (-13002): Communication timed out while sending control packets to the PMU.
  • pmRecAgntErr (-13003): The system timed out waiting for a reply from the power hardware.

MacsBug Crash Logs

Because Mac OS 9 did not automatically commit crash dumps to disk during a freeze, Apple’s official low-level assembly debugger, MacsBug, was the primary diagnostic tool for diagnosing power management failures.

When a driver or extension failed during a power transition with MacsBug installed, the system halted execution and dropped into an interactive terminal screen. If the disk driver was still responding, users could execute the log command to write the session output to a text file named MacsBug Log in the root System Folder.

A MacsBug power management report provided:

  • The Disassembly Window: Showed the specific assembly instructions running inside the Power Manager extension (PowerBook Sleep, Energy Saver, or native CPU Plugins).
  • Stack Crawls (sc command): Revealed whether the crash originated in the sleep queue handlers (SleepQueue), external device drivers, or USB/FireWire controller sleep handlers.
  • Register Dumps: Outlined the processor state at the exact moment a power transition stalled.

Open Firmware Diagnostics and Serial Logging

For deep power hardware failures where the operating system could not boot or initiate sleep, Mac OS 9 machines utilizing the New World ROM architecture relied on Open Firmware. When debugging sleep and wake issues across custom hardware configurations, developers could configure Open Firmware to route output to an external machine via a serial connection.

If the Power Management Unit (PMU) or Core99 chipset failed during sleep assertion, Open Firmware output captured the point of failure before the Mac OS 9 ROM wrapper could initialize video or disk services.

Hardware Testing and NVRAM State

If sleep failures were caused by corrupted hardware state tables rather than software conflicts, no software log would generate. In these cases:

  • Apple Hardware Test (AHT): Technicians booted from physical diagnostic CDs containing targeted routines to test the PMU, battery controllers, and internal power buses, outputting specific diagnostic failure codes (e.g., errors under the 2PMR or 2PMU categories).
  • Parameter RAM (PRAM) and NVRAM: Power preferences and device sleep trees were saved directly to NVRAM. Corruption within these parameters caused recurring wake-up failures, requiring a manual hardware PRAM reset or a motherboard PMU reset button press to clear the invalid power state tables.