How to Save a Legacy Hackintosh IORegistry Dump (GUI & CLI)

When you finally have a Legacy Hackintosh running with stable sleep, working audio, and accelerated graphics, the IORegistry dump becomes the single most important diagnostic artifact for that build. Unlike a screenshot of Clover or a config.plist snippet, a full IORegistry capture records every device node, injected property, and driver match in the kernel's object tree at the moment of capture. Saving this dump correctly — and with the right metadata — ensures you can reproduce, compare, or share your hardware configuration without needing the physical machine plugged in, months or years later.

The IORegistry is the macOS kernel's live database of all I/O Kit objects. Every PCI device, USB controller, audio codec, and ACPI thermal zone appears as a node with its own set of properties. When you inject a kext or an SSDT, the resulting changes appear in the registry. A saved dump therefore acts as a snapshot of exactly what macOS saw after your bootloader and patches applied. Without it, you are debugging blind after a macOS update or a hardware swap.

This guide covers the two primary methods to save an IORegistry dump — the GUI approach with IORegistryExplorer and the command-line ioreg tool — along with the flags, file formats, and naming conventions that keep your archive useful. Both methods are equally valid; the choice depends on whether you prefer a visual tree or a plain-text file that can be grepped, diffed, or stored in version control.

Why Save a Dump? The Practical Reasons

A saved IORegistry dump serves several distinct purposes that go beyond the immediate debugging session:

• Regression testing: After updating macOS from 10.13 to 10.14, compare the dump of the new system against the old one to see which device properties changed or disappeared.
• Build documentation: Attach the .ioreg file to your build notes so that if you need to rebuild the same machine six months later, you can verify that every kext injection hit the correct IORegistry entry.
• Remote troubleshooting: Share a saved dump with a fellow enthusiast without granting them remote access to your machine. The dump is read-only and contains no personal data beyond hardware identifiers.
• Self-archiving: When you sell or decommission a board, you keep the dump for future reference. A Gigabyte GA‑Z77X‑UP5 TH from 2012 still has its IORegistry quirks; a saved dump can help you answer a forum question years later without owning the hardware.

Each of these scenarios requires that the dump be saved exactly as the kernel saw it, with no post-processing or truncation. The methods below guarantee that.

Method 1: Saving from IORegistryExplorer (GUI)

IORegistryExplorer (versions 2.x and 3.x) provides a rich tree view of the IORegistry. The “Save As” command is straightforward, but several options affect the quality of the dump.

1. Launch IORegistryExplorer with the appropriate version for your macOS. For 10.6–10.9 use v2.x; for 10.10–10.15 use v3.x. Running the wrong version can produce a truncated registry.
2. Refresh the tree by pressing Cmd+R to ensure the view is current. If you have just plugged in a USB device or loaded a kext, the tree may not reflect it until refreshed.
3. Go to File → Save As (or Cmd+S). The default format is .ioreg, a proprietary binary format that preserves the exact tree structure and all properties.
4. Choose compression. In the save dialog, you can check “Compress” to produce a .ioreg.gz file. This is recommended for archival because it reduces file size by 80–90% without losing any data. The compressed file is still readable by IORegistryExplorer — it decompresses on open.
5. Save the file to a dedicated folder, ideally inside your build’s documentation directory alongside the Clover/OpenCore config, kext collection, and SMBIOS notes.

One common mistake: saving the dump while the machine is in a sleep or partial wake state. The IORegistry will show many devices as “not running” or with missing children. Always save the dump after a fresh boot or after the system has been fully awake for at least 30 seconds.

Method 2: Saving from the Command Line with ioreg

The ioreg command-line tool ships with every copy of macOS and does not require any third-party application. It outputs the IORegistry as plain text, which is ideal for searching with grep, comparing with diff, or including in a text-based build log.

ioreg -w0 -l > ~/Desktop/ioreg_dump_$(date +%Y%m%d).txt

Break down the flags:

• -w0: Sets the output width to unlimited. Without this flag, macOS truncates long property values (such as IODisplayEDID or RM,board‑id) to 80 characters. For archival purposes, you always want full width.
• -l: Lists all properties for each node. Without -l, the output only shows the node names and their class, which is useless for diagnostics.
• -p <plane> (optional): By default, ioreg dumps the IODeviceTree plane. You can also dump the IOService plane with -p IOService or the IOUSB plane with -p IOUSB. For a full snapshot, omit the -p flag; the default is sufficient.
• -r (optional): Root-only mode. Dumps only the root node and its immediate children. Not recommended for archival.

The output is a plain text file with indentation showing the hierarchy. Each line looks like:

  | |   +-o IOPCIDevice@0  <class IOPCIDevice, id 0x1000001e1, registered, matched, active, busy 0, retain count 9>
  | |     {
  | |       "IOClass" = "IOPCIDevice"
  | |       "vendor-id" = <108086h>
  | |       "device-id" = <1086h>
  | |     }

This format is easily parsed by scripts. For example, to extract all vendor‑id values, run grep vendor-id ~/Desktop/ioreg_dump.txt.

Compressing the Text Dump

Text dumps can be large — 2–5 MB for a typical Legacy Hackintosh with many PCIe devices. Compress them with gzip or zip before storing:

gzip ~/Desktop/ioreg_dump_20250315.txt

Unlike the GUI method, the command-line output does not include a “Refresh” button — you are capturing exactly what the kernel reports at the moment the command runs. To ensure consistency, run the command after the system has been idle for a few seconds and after any USB devices have been enumerated.

Comparing Saved Dumps

Once you have two dumps — for example, one from macOS 10.13 High Sierra and one from 10.14 Mojave on the same hardware — you can compare them to detect changes in driver matching or property injection.

• Text dumps: Use diff -u old.txt new.txt to see added, removed, or changed lines. Ignore changes in “retain count” and “busy” values; focus on properties like IONameMatch, IOPCIClassMatch, and vendor/device IDs.
• IORegistryExplorer .ioreg files: Open both files side by side in IORegistryExplorer. The app does not have a built-in diff tool, but you can collapse/expand both trees and manually check the same node. For a more efficient workflow, convert the .ioreg files to text using the command line: ioreg -w0 -l -o /path/to/file.ioreg (yes, ioreg can read .ioreg files).

When comparing, pay attention to nodes that appear in one dump but are missing in the other — this often indicates a kext that failed to load, a device that is not being matched, or an ACPI table that was not applied.

Best Practices for Naming and Metadata

An unnamed dump file is useless six months later. Adopt a naming convention that includes:

• Date in ISO 8601 format: 2025-03-15
• macOS version: 10.14.6
• Hardware shorthand: z77x-ud5h or optiplex-7010
• Method: ioreg or ioregexplorer

Example: 2025-03-15_10.14.6_z77x-ud5h_ioreg.txt.gz

Store the dump in a folder that also contains the exact config.plist, kexts used, and a note about any special boot flags. This combination allows you to fully reconstruct the software environment that produced that IORegistry state.

Common Pitfalls and How to Avoid Them

One final nuance: the ioreg command cannot capture the exact state of the IODeviceTree after a kext has been unloaded in a specific order. If you are debugging a kext that unloads on sleep, save the dump both before and after sleep to capture the differences.

After you have saved your first dump, open it in IORegistryExplorer six months later to verify that your kext injections still target the same device paths. That single check can save hours of re‑diagnosis when you decide to rebuild your Legacy Hackintosh from scratch.