• What version of Mono are you running?
  • Use mono --version and rpm -qiv $(rpm -qa | grep mono) to determine this.
• What application were you running?
• What kind of error occurs? Do you get a stack trace? Native crash? Garbled output?
• Is the issue reproducible on other systems?
  • (If possible) Is it reproducible on Linux? Linux/ppc64be? Windows?
• Is it reproducible on different (older, newer) versions Mono?

Tracing makes Mono print information about each function call and return, including arguments. You can enable comprehensive tracing with --trace=all, but this produces very long traces. (I recommend you redirect standard output to a file, i.e command > file.) If you suspect you know where the problem is, you can have a finer-grained trace:

$ mono --help-trace
Tracing options:
   --trace[=EXPR]        Trace every call, optional EXPR controls the scope

EXPR is composed of:
    all                  All assemblies
    none                 No assemblies
    program              Entry point assembly
    assembly             Specifies an assembly
    wrapper              All wrappers bridging native and managed code
    M:Type:Method        Specifies a method
    N:Namespace          Specifies a namespace
    T:Type               Specifies a type
    E:Type               Specifies stack traces for an exception type
    EXPR                 Includes expression
    -EXPR                Excludes expression
    EXPR,EXPR            Multiple expressions
    disabled             Don't print any output until toggled via SIGUSR2

Mono can print out information from the runtime with an environment variable set, and filtered. This is especially using for debugging P/Invoke.

If the runtime starts crashing in native code, it may be useful to perform debugging at the SST level. Tony Cairns (formerly of IBM) has written a guide on how to debug PASE-related crashes. At minimum, looking at the stack trace from a core dump is actually easy with SST; it shows lots of useful information.

Debugging at runtime with Unix tools is possible too; dbx was previously too incapable of completing the task, but now gdb has been ported to PASE (available via Yum), and can be quite useful. (I have found signal handlers can disrupt some debugging features, so it is useful to determine where your bug is, and set a breakpoint just before it.) Mono's website has information on how to work with the runtime inside of GDB.

Sometimes, nothing helps more than working with the source and printing out information in exactly the right place. Look at how to build from source for some specifics, but you can usually work from a cloned repository/installed prefix; git can be quite useful in this situation.