How to Save and Use IORegistryExplorer Dumps for Hackintosh Debugging

Most Hackintosh users open IORegistryExplorer, spot a missing property, find the culprit, and close the app without ever hitting Save. A few weeks later, when the same machine shows a different symptom—or a forum helper asks for a .ioreg file—you have to reproduce the exact same state. That may be impossible after a driver update, a macOS reinstall, or a hardware swap. IORegistryExplorer 3 (the last version that runs reliably on macOS 10.6 through 10.15) has a save function that writes the entire registry tree to a compressed binary file. This article covers when, how, and why to save these dumps, and how to use them for offline analysis, configuration versioning, and collaborative debugging.

What the Save Function Actually Captures

IORegistryExplorer 3 saves the full I/O Kit registry plane, not just the IOService plane that the GUI displays by default. The file includes every entry, property, and integer value from the kernel’s object hierarchy at the moment of capture. The file format is a flattened binary plist with a .ioreg extension. Unlike a plain-text ioreg -l output, the saved file preserves the exact tree structure, including memory-backed data such as IOPropertyTable entries that are not always printed by the command-line tool. This makes it indispensable for inspecting properties that are only present at boot time or are dropped after a device is configured.

Common use cases include:

• Verifying that a custom SSDT injected the correct device-id or vendor-id for a graphics card.
• Comparing a working configuration with a broken one to identify missing IOPCIPrimaryMatch entries.
• Providing a reproducible snapshot to a remote helper without exposing your full EFI folder.
• Archiving the exact state of a build before a macOS upgrade, so you can roll back driver patches if the upgrade fails.

How to Save a Dump Correctly

The process seems simple, but a few details matter. Launch IORegistryExplorer 3, then from the File menu choose Save As…. The default format is IORegistryExplorer 3 Document (extension .ioreg). Do not change the format to XML or plain text—those are lossy and omit the registry plane metadata. The resulting file is typically 500 KB to 3 MB depending on the number of devices and drivers loaded.

Before saving, ensure the registry is fully loaded. If you are debugging a device that initializes late (e.g., a USB controller after a SSDT hotplug), wait until the device appears in the GUI plane. A common mistake is to save the registry immediately after boot, before the window server and graphics drivers have populated the IOGraphics plane. Wait at least 30 seconds after the desktop is fully visible, then verify that the target device shows up in the list.

Naming Conventions

Adopt a consistent naming scheme. A good pattern includes the build identifier, the macOS version, and a short description of the state:

• Z77-DS3H_10.13.6_working_nvidia_graphics.ioreg
• Z77-DS3H_10.13.6_after_ssdt_lpc_fix.ioreg
• Z77-DS3H_10.13.6_broken_audio.ioreg

This makes it trivial to diff two files months later without having to recall what each snapshot represents.

Reading Saved Dumps Without IORegistryExplorer

The .ioreg file is a binary plist. On any macOS system, you can open it with Property List Editor (Xcode) or PlistEdit Pro. The root node is a dictionary with a key IOKitRegistry that contains the full tree. You can also convert it to XML using plutil -convert xml1 file.ioreg -o file.plist and then inspect it with a text editor. For command-line work, plistutil (from libplist) works on Linux, but the binary format is not guaranteed to parse on older Windows systems. If you need to share a dump with a Windows user, convert it to XML first.

Comparing Two Dumps: A Practical Workflow

When diagnosing a regression, the most effective technique is to save a baseline dump on a fully working system, apply a change (e.g., a new kext or a modified SSDT), then save a second dump. Compare the two files using a diff tool that understands plist structure. The FileMerge application (bundled with Xcode) can display the differences in the hierarchical property list. Alternatively, diff the XML-converted versions, but be aware that the order of dictionary keys may not be stable, producing false positives.

For example, when debugging Intel HD Graphics 3000 injection on macOS 10.7–10.13, saving the ioreg output before and after applying a framebuffer patch allows you to verify that the appleigpu properties are correctly populated. A missing IOPCIMatched entry or a wrong device-id will show up immediately in the diff. This technique is covered in detail in our Intel HD Graphics 3000 on Hackintosh: A Practical Guide for macOS 10.7–10.13, where saved dumps are used to confirm each step of the injection.

For NVIDIA Kepler cards on newer macOS versions, the same approach applies—save the registry after the NVDAGK100Hal kext loads, then compare with a known-good dump from a build that had working acceleration. The NVIDIA Kepler GPU Configuration for macOS 13 Ventura Hackintosh guide includes example diffs that highlight the exact properties that must be present.

Archiving Dumps for Future Rebuilds

Legacy hardware often requires reinstallation years later, when the original EFI configuration may have been lost or when the macOS version is no longer available for download. If you keep a folder of saved .ioreg files alongside your EFI backup, you can reconstruct the exact kext injection patches without relying on memory. The saved dump tells you which IOPersonality entries were matched, which IOProbeScore values were used, and which device properties were present at boot. This is especially valuable for platforms like Sandy Bridge or Ivy Bridge where the ACPI tables are often missing critical entries.

Store the dumps in a separate directory with a readme that lists the date, macOS version, bootloader version, and the purpose of each snapshot. If you use version control (e.g., git) for your EFI folder, commit the .ioreg files as binary assets. Git will handle them fine as long as you do not try to diff them directly.

Risks and Limitations

Saved dumps contain information about your hardware identifiers, including serial numbers from the platform, GPU ROM, and sometimes the MLB (Main Logic Board) string if you have injected it. Treat these files as sensitive. Do not upload them to public forums without first redacting the IOPlatformSerialNumber and IOPlatformUUID entries. You can edit the plist with a text editor after converting to XML, or use a script to strip those keys before sharing.

Another limitation: IORegistryExplorer 3 cannot save the IODeviceTree plane independently—it always saves the combined tree. If you need to inspect the device tree separately, use the command-line ioreg -w 0 -r -p IODeviceTree and redirect the output to a file. But for most property-level debugging, the saved .ioreg file is sufficient.

Final Workflow Checklist

Before you close IORegistryExplorer 3 after a debugging session, ask yourself:

• Did I save the dump with a descriptive name?
• Did I wait for all devices to initialize?
• Did I capture both a baseline and a post-change dump when applicable?
• Did I store the files in a location that will survive a drive reformat?

Save the file, name it clearly, and stash it alongside your EFI backup. Months later, when that machine acts up again, you’ll have a time capsule of its exact kernel state—no guessing, no rebuilding from scratch.