How to find, read and use the debug logs after testing


Check out SCORM Cloud now!

[catlist slug=scorm-cloud-products header=”Recent Blog Posts” ]

Test Track Sandbox

That’s right. At its core, SCORM Cloud provides a tool that allows for testing content. Many LMSs simply work or don’t, but they don’t allow an author or tester to understand why something’s gone wrong. Like Firebug and Fiddler for the browser, SCORM Cloud’s testing feature is the premier diagnostic tool for SCORM content.

Finding the Debug Logs

Step one in debugging content is finding the diagnostics themselves. This is done from the Navigation Bar by clicking on the “Show Debug” link shown here. It is often beneficial to click around through your content a bit before launching the debug log. Also of note, the debug logs launched from the content window contain the details of this launch session. If you want to click through several SCOs, go for it… all of that data will be present.


More Anatomy

The debug window is made up of three primary sections.


  • Activity State: The first section (orange in the picture) contains a real-time representation of the entire activity tree. By expanding the plus icons to the left, you can drill into both activity data and the run-time data (yes, they’re different).
  • Advanced Section: The advanced section, frankly, is rarely used even here.
    • Possible Navigation Requests gives you an insight into the “Look Ahead Sequencer” that a part of the SCORM Engine. While this functionality is powerful and important from a usability perspective, it rarely requires examination.
    • Global Objectives are a sophisticated SCORM construct that allow for certain pieces of data to be shared between SCOs. These are handy for advanced SCORM 2004 sequencing scenarios.
    • SSP Buckets are key to supporting the IMS Shareable State Persistence (IMS SSP) standard, an option on SCORM Engine implementations.
  • Run-time Interactions and Sequencing Trace: This log contains every interaction between the content and LMS. In SCORM, each and every interaction is initiated by the content. Using a collection of eight methods, the content get data, set data, and check for errors. Also included in the Log section is a trace of the SCORM 2004 sequencing execution. These red elements include references (like [OP.1]) to specific pseudocode algorithms found in the SCORM specifications themselves. Using these logs, it is possible to determine precisely why the sequencer behaves as it does.
What to look for when you test your content

While it’s impossible to test your content like the SCORM test suite would, these are a few things worth checking in your content:

  • Does it launch? Seriously, a lot of content is packaged so poorly that when it arrives in the LMS, it simply points to a page that isn’t there, resulting in a 404 page or something similar. If you’ve got some content showing, you’re doing well.
  • Does it communicate? This is another common misstep. Launch the debug logs as discussed above. Look in the Log section (Run-time Interactions). Do you see any blue at all? If you see only red lines, this is because the content has failed to find the API provided by the LMS. This, frankly, is a mistake on the part of the content, but there are some Package Properties that can help overcome this issue. Start by trying your content launched in the frameset (Launch Properties) instead of a new window. If that fails, try wrapping the window in the API (compatibility settings).
  • Does the content ever complete? At some point, your content should tell the LMS that the learner is done. Do you know where that happens? Can you force it to happen? Is it passing the statuses you expect? Look for lines with the words “completed” or “passed”.

If things are looking good here in the debug log, the next step is to check that the rolled up status shown on the course status page (back in the library section of SCORM Cloud) shows what you would expect it do.