Logging

Logs and diagnostic exports

Logs and original report files make hardware failures possible to investigate. A description gives context; it usually cannot replace evidence. Export files from one labeled test run and say which build actually ran, what you did, and when.

From the ASFW app

1. Open System Logs, reproduce the failure, and use Export Logs. Include startup as well as the failure; snippets can hide the initialization that caused it.
2. Export 1394 Diagnostics using Save to .txt... when the driver is connected and the report contains useful controller, topology, or transaction information.
3. For DICE/TCAT hardware, export the DICE Report when available.
4. For AV/C hardware, save the AV/C Report, preferably the JSON dump retaining command/response detail. Export labels can differ between builds. Refresh reruns discovery; lower speaker/headphone levels before actively reprobeing a device.
5. Attach driver .ips reports for crashes from /Library/Logs/DiagnosticReports/, matching net.asfw.driver-*.ips (or the old identifier for an older build).

Attach the original files, or a ZIP of one run, instead of pasted/reformatted text. If a report is unavailable, explain why. A blank “driver not loaded” diagnostic export is not useful device evidence: collect extension status and system/crash logs instead.

Reports cover different things: 1394 diagnostics describe bus/controller state; DICE reports describe device registers, geometry, clock and available routing; AV/C reports describe discovery/control exchanges; system logs record startup and events. A report showing streams or counters does not establish nonzero or correct audio.

System logs when app exports are unavailable

systemextensionsctl list
/usr/bin/log show --last 20m --info --debug --style compact \
  --predicate 'eventMessage CONTAINS "[Controller]" OR eventMessage CONTAINS "[AudioHost]" OR eventMessage CONTAINS "[RME]" OR eventMessage CONTAINS "LogConfig initialized"' \
  > ~/Desktop/ASFW-system-log.txt

Use /usr/bin/log explicitly: zsh's log builtin can shadow it. Pass --info --debug. DriverKit messages may appear under process kernel; filter message tags, not just process == "net.asfw.driver". Console.app can also export relevant system messages. For a family-specific investigation, add the tags requested by the maintainer.

A live I/O Registry service can belong to a crashed/restarted or incomplete driver. Look for the startup build and LogConfig initialized line, and check crash reports. An activated extension with no successful startup evidence needs installation/startup investigation before interpreting downstream audio symptoms.

Include with the files

Mac model/architecture, macOS version/build, device/revision/firmware if known, ASFW app and loaded driver versions, connection chain, test time, reproduction steps, physical playback/capture result, rate/channels, and power-cycle/reconnect conditions. See Reporting Issues for a compact checklist.

Developer telemetry contracts and category inventory remain in Audio telemetry snapshot. Optional MCP diagnostics are described in Development.