How do you debug a FreeRTOS system that crashes or behaves erratically?

I'd start with the usual suspects that FreeRTOS gives you tools for. Stack overflow is the most common cause of erratic, hard-to-explain behavior because without an MMU an overrun silently corrupts adjacent memory: I enable configCHECK_FOR_STACK_OVERFLOW with a vApplicationStackOverflowHook to trap it, and use uxTaskGetStackHighWaterMark to see how close each task came to its limit and resize accordingly. I wire configASSERT to a handler/breakpoint, because the kernel asserts on a wide range of misuses, most importantly a wrong interrupt priority (an ISR above configMAX_SYSCALL_INTERRUPT_PRIORITY calling a FromISR API), but also NULL handles, calling blocking APIs from an ISR, or from before the scheduler starts; that assert alone catches a large fraction of FreeRTOS bugs. For "a task isn't running" or CPU-hogging issues, I use run-time stats (vTaskGetRunTimeStats) or a trace tool (like Tracealyzer) to see per-task CPU usage and whether the idle task ever runs, if idle never runs, a task isn't blocking; if a low-priority task never runs, suspect starvation. For hangs, I check for deadlock (inconsistent lock ordering) and priority inversion (resource guarded by a semaphore instead of an inheriting mutex). I verify heap usage (xPortGetFreeHeapSize) and whether vTaskStartScheduler returned (out of heap). And for a hard fault, I read the Cortex-M fault status registers and the stacked PC to localize the offending instruction. The throughline is that FreeRTOS provides specific instrumentation, overflow hook, high-water marks, configASSERT, run-time/trace stats, heap queries, so debugging is methodical rather than guesswork, and the top culprits are stack overflow, interrupt-priority misconfiguration, and the concurrency bugs (deadlock, inversion, races) from the rest of this module.