Troubleshooting, known bugs and more...


  Spectrum Lab's Error History
  CPU Load Display
  How to report bugs
  Running the program in "debug"-mode, producing a logfile
  Buglist / User's Group
  Spectrum Lab's main index

Spectrum Lab's Error History

Spectrum Lab's own (internal) Error History is one of the first things you should check if the program behaves strange, audio isn't ok, input signal are not displayed, etc.
To open the error history, select 'View/Windows' in SL's main menu, then click on 'Error History'.
The error history is displayed in one of the tabsheets in a window titled 'Debugging Display':

Screenshot of SL's Error History display window,
showing a few 'minor problems' after launching

Note: The 'error history' also shows additional information which may help debugging.
Not all lines in the error history are actually errors. The 'real' errors can also be logged to a file, as explained in another chapter.

Real error messages are displayed with a red background.
Warnings (e.g. suspicious parameters) have a yellow background.
Everything else (debugging info, etc) uses the default white background, as in the older screenshot shown above.

When 'real errors' occurr, the error history automatically pops up, unless the option 'auto-open' (on the Error History tab) is unchecked.

Spectrum Lab's CPU Load Display

When running certain applications in Spectrum Lab, the CPU may not be fast enough in some cases.
The total amount of CPU time (percentage) can be examined in the windows task manager (or whatever Microsoft decided to call it today..), but the task manager cannot tell you which of the different threads and functions in Spectrum Lab consumes the most CPU time (and thus can be optimized to reduce the CPU load).
To open SL's own CPU load indicator, select 'View/Windows' .. 'CPU load' in the main menu.
This opens another tab in the 'Debugging' window, which may look as shown below:

Screenshot of SL's CPU load display

Note: As most windows in Spectrum Lab, the 'Debugging' window is sizeable.
The 'total CPU load' percentage, shown at the bottom of that window, assumes that all threads are running on a single core (CPU). Because the audio processing, the FFT calculation, and the display update may run in different threads on different cores (in a multi-core CPU), the 'total CPU load' may exceed 100 percent without problems on such machines.

How to report bugs

If you encounter any problems with this program, follow these steps..

  1. Read the manual or online-help system.
  2. Don't miss the chapter "System Requirements and Installation".
  3. Please Check For Updates before wasting your (and my) time searching for a bug which has possibly been fixed already.
  4. Visit the SL User's group and check if the problem is already known, and if there is some kind of work-around.
  5. Try to install the program on an other PC and try if the problem occurs on that PC, too
  6. Reduce the sample rate, turn off all unused components
  7. Close all other applications that run "in the background"
  8. Run the program again, this time in debug mode, and check the logfile after a debug-run
  9. If the bug causes a program- or even a system crash, please read this (and check the error log).
  10. Check the User's Group (see link below); if the problem is windows- or hardware-related other users may have posted a workaround.
  11. If still no cure found, send me an error description via email including the following points:
The preferred method to reports bugs is via the Spectrum Lab User's Group at Yahoo.
You may find similar bug reports there, and possibly there is already a solution if the problem is related to a certain version of windows, or a certain hardware. If you are not using the latest version of Spectrum Lab, the author will most likely not be able to help. So, before you post a problem, make sure you have an up-to-date version as explained here.

top of page

Running the program in "debug"-mode, producing a logfile for post-mortem analysis

In some tough cases (were the program seems to crash, or locks up), you can help to find the problem using a special debugging feature which is built into Spectrum Lab.

When started with the command line parameter /debug, the program will produce a textfile named "debug_run_log.txt" in the installation folder (i.e. the directory where SpecLab.exe has been installed). Each line in that file is marked with the time-of-day, and a rather cryptic description of what has happened, or what went wrong (if the program had the chance to detect that before "dying"). If you create a desktop icon for SpecLab, you can modify it (right-click the icon, then select "properties" (or "Eigenschaften" on a german PC). After the path and filename of the executable, append a single space character, and the /debug switch. The result should look like this:

C:\Spectrum\SpecLab.exe /debug

Then start the program by clicking on the modified icon, or entering the above line on the windows command prompt. If you don't know how to run a program from a command line under windows: A nice how-to used to be here.
Alternatively, the installer should have added an item in the windows 'Start' menu under 'All Programs'..'Spectrum Lab'..'Run Spectrum Lab in debug mode'.
This item launches a batch file, which in turn launches Spectrum Lab with the '/debug' switch as explained above. After SL terminates, the batch file shows the contents of the debug log in an extra console window.
After running Spectrum Lab with the 'debug' switch, the first few lines in the (debug-) logfile may look like this:

19:38:45.9 Logfile created, date 2012-10-15
19:38:45.9 checking instance...
19:38:45.9 Executable: c:\cbproj\SpecLab\SpecLab.exe
19:38:45.9 Compiled  : Oct 15 2012
19:38:45.9 Data Files: c:\cbproj\SpecLab
19:38:45.9 init application...
19:38:45.9 creating main form...
19:38:46.0 Constructing main form
  ... (many lines removed here) ... 
19:38:49.7 Sound devices started
19:38:49.7 Back from InitAudioDevices .
19:38:51.1 Launching Sound Thread
19:38:51.1 Clearing digimode chunks
19:38:51.1 Clearing audio chunks
19:38:51.1 Entering audio thread loop
19:38:51.1 First call of RunProcessingChain() ..
19:38:51.1 Back from RunProcessingChain()  

If all went well, after quitting Spectrum Lab in 'debug' mode, the last lines in the logfile should look similar to this (there may be more, of course):

19:38:55.7 Beginning to close ....
  ... (many lines removed here) ... 
19:38:59.4 Deleting SPECTRUM objects
19:38:59.4 Deleting other buffers
19:38:59.4 FormClose done
19:38:59.4 Ok, all 85 dynamic memory blocks were freed.
19:38:59.4 Reached last termination step; closing logfile.

If you find strange looking lines with one of the following messages in the logfile....

... then please send me a copy of the entire logfile (debug_run_log.txt) via email, or (preferred) to the Spectrum Lab User's Group mentioned in the next chapter.

Buglist (moved to the SL User's group)

As of 2012, an up-to-date list of bug reports, and possible fixes, was at the Spectrum Lab User's Group at Yahoo.

top of page