shownotes_MCM20111107

Console
  Error logs can often be a useful tool in trying to troubleshoot the Mac. The trick is figuring out how to read them and to know what to look for. The Console is a useful tool built in to Applications-->Utilities that can help.
Layout
  The general layout of the Console should be familiar because it uses the classic 3 panel layout
  The toolbar
    Quick access to common function
    View-->Customize Toolbar to add or remove items
    Has search/filter box
  Log List
    List of available logs
    Pre-organized into 3 main categories: System Log Queries, Diagnostic and Usage Information, and Files
  Sender and Tag Pane
    May need to be expanded
    Visible when viewing logs
    Has two tabs: Senders and Tags
  Main Messages window
    Contains the actual log details
    In some cases information may be grouped and collapsed. Expand using the disclosure triangles
Log List
  System Log Queries
    All Messages: Default and displays all log messages
    Build your own query:
      File-->New System Log Query
      Enter a name for your search: i.e. 'Twitter Unavailable'
      Define criteria, 'Sender'->'contains'->'Twitter'
      Click the "+" to add additional criteria. "Message"->"contains"->"service unavailable"
  Diagnostic and Usage Information
    "Crash reports"
    Separated into User and System
    There will be multiples per application/thread. Each one being a crash incident.
    The name will generally indicate the offending application
  Files
    Separated into 5 main parts: system.log, kernel.log (OS system and BSD kernel), ~/Library/Logs (User level application logs), /Library/logs (System level application logs), /var/log (Core BSD services logs)
    Your probably mostly interested in the system.log and ~/Library/Logs files
    /var/log has cool stuff if your looking for stuff like 'cups' or 'windowserver', also apache logs or launch daemons
Reading and parsing log files
  Once you find the log you want to look through there are some useful tools
  Filter. Use the search box to narrow down the results to look for specific messages.
  Looking for specific 'Senders'
    The application that triggered the log entry
    View-->Show Sender Icon Or Show->Sender in Bold
    Ignore Sender. Select an item in the main window and use the toolbar option 'Ignore Sender' to hide all messages from that sender in the list.
    Open the 'Senders' and 'Tags' pane and select specific sender to display by checking the boxes. You see you can also remove any ignored senders from this pane as well.
      Control the number of Senders and tags displayed in that pane from Console-->Preferences-->Number of Top Senders & Tags option
  Clear Display. From toolbar or View-->Clear Display (Command+K) Rest the view so you only see new incoming messages. Hit reload to load the full log again
    At the bottom the 'Earlier' and 'Later' buttons will allow you to see older entries that might be beyond the Console's display limits.
  Insert Marker. Adds a time stamp "#Marker" tag so you can set a point in the log that you can filter on
    other 'Tags' are set by the developers and may appear in the pane so you can filter on those by checking them.
  Using the Inspector
    Select an item in the main log window and bring up the inspector by clicking the toolbar item or from Window-->Message Inspector (Command+I)
    Give you a nicer "grid" key/value view
    Easily see key info like the Sender, PID, and Message.
    Use the PID and launch the Activity Monitor to match the process in the Activity monitor.
Reading Diagnostic Reports
  This is what used to be called, "Crash Reports".
  The first batch of stuff shows what process crashed

    Process: Dock [341]
    Path: /System/Library/CoreServices/Dock.app/Contents/MacOS/Dock
    Identifier: Dock
    Version: ??? (???)
    Code Type: X86-64 (Native)
    Parent Process: launchd [319]

  Operating System, date and time

    Date/Time: 2011-11-02 12:15:50.800 -0700
    OS Version: Mac OS X 10.7.2 (11C74)
    Report Version: 9

  The Exception (type of crash)

    Exception Type: EXC_BAD_ACCESS (SIGBUS)
    Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff710ffc10

    Basically Apple defines 4 types
      EXC_BAD_ACCESS/KERN_INVALID_ADDRESS - This is caused by the thread accessing unmapped memory. It may be triggered by either a data access or an instruction fetch
      EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE - This is caused by the thread trying to write to read-only memory. This is always caused by a data access.
      EXC_BAD_INSTRUCTION - This is caused by the thread executing an illegal instruction.
      EXC_ARITHMETIC/EXC_I386_DIV - This is caused by the thread doing an integer divide by zero on an Intel-based computer.
  The Backtrace
    The threads in reverse chronological order that lead up to the crash
    You'll know which thread crashed because it will say, "thread X crashed"
    Under the crashed thread you have in reverse chronological order the the tasks that lead up to the crash
      The first column indicates order
      The second column indicates the name of the program or other system component that performed the task.
      The third column is the counter program address (e.g. 0x16bf2c34) - basically a hash
      The fourth column displays the task (i.e. _objc_empty_cache + 0)
Why bother?
  So knowing all of this you can get a bunch of technical info, but what good does that do you?
  You may be able to see what was going on within and app or your system on or around the time of a crash and that may help you pinpoint a cause
  You can get a specific message or error to perform a Google search with that may yield a fix or work around.