A user's MacBook Air running macOS Ventura is experiencing intermittent kernel panics. The crashes seem to occur when the laptop is connected to a specific USB-C hub. Which macOS tool should you use to analyze the crash logs and identify the faulty driver?
Console allows you to view kernel panic logs and filter them by date and process to identify the problematic driver.
Why this answer
The Console app is the correct tool because it provides a centralized interface for viewing all system logs, including kernel panic reports (stored in /Library/Logs/DiagnosticReports). When a kernel panic occurs, macOS generates a .panic file containing stack traces and loaded kext (kernel extension) information. By examining these logs in Console, you can identify the specific kext or driver (e.g., a USB hub driver) that triggered the panic, especially when the crash is hardware-dependent like this USB-C hub scenario.
Exam trap
CompTIA tests the misconception that System Information or Activity Monitor can retrieve historical kernel panic reports. While System Information shows hardware and software details, and Activity Monitor shows live resource usage, the Console app is the standard tool for viewing persistent kernel panic reports and system logs across reboots.
How to eliminate wrong answers
Option A is wrong because System Information provides a static snapshot of hardware and software configuration (e.g., USB device tree, kext versions) but does not display real-time or historical crash logs; it cannot show the dynamic stack traces needed to pinpoint a faulty driver. Option C is wrong because Activity Monitor shows running processes, CPU/memory usage, and system resource statistics, but it does not capture kernel panic logs or driver-level crash data. Option D is wrong because 'sudo dmesg' displays kernel ring buffer messages from the current boot session only; after a kernel panic and reboot, the dmesg buffer is cleared, so it cannot show the panic log from the previous crash.