KDebugDialog is not in the K menu by default. You will need to run it from the shell or from the mini-CLI with the command kdebugdialog . KDebugDialog pops up a window with a long list of debugging areas. Each area has a checkbox that you can check or uncheck in order to enable or disable debugging output for that part of KDE.

The list of debugging areas is sorted numerically, not alphabetically, so kio (127) comes before artskde (400). The numbers go up to 200000 or so, but there are really only 400 areas. You don't have to scroll through the entire list to find the area you need, though. There is a line edit box at the top of the dialog where you can enter a part of the name of the area you want. The list of entries that is displayed is filtered to include only those debug areas that contain the text you have entered. e.g. entering k does not filter very much at all, but entering kont will show you just the Kontact debugging areas. As an even quicker way of enabling or disabling debugging output, there are also select all and deselect all buttons which will cause KDE to produce a mountain of debugging output, or very little.

In full mode, which is what you get when you start kdebugdialog as kdebugdialog --fullmode , the same list of debugging areas as in plain mode is available, but you can select only one at a time from a drop-down box. You may then independently set the output for various types of messages: Information, Warning, Error and Fatal Error. For each of these types, you can choose where the messages are sent. The choices are:

File, in which case you can enter a filename. This file is written into your $ HOME directory.

Message Box. Each debugging message is displayed in an information dialog, which you must OK to continue with the application.

Shell, the default entry. Messages are printed to stderr, and will appear either in the shell window where the application was started, or in .xsession-errors.

Syslog. This sends each debugging message to the system's syslog facility, which can perform its own processing of the message.

None. This suppresses the output of this type of message.

For messages generated by fatal errors, it is generally a bad idea to choose None or Syslog, since in both cases you most likely will not see the message and the application that encounters the fatal error will vanish without leaving a clue as to why it vanishes. Whether or not the application will vanish on fatal errors can be controlled by the checkbox abort on fatal errors , which is checked by default — but you might expect an application to crash (in a messy fashion) if a fatal error is encountered anyway.