Attaching J-Link to a running STM32F205 without resetting — symbols not resolving

Hello Keil team,

I'm debugging an STM32F205-based device that runs a bootloader and an application, both using CANopen. There's a bug that only manifests in a specific power-up race condition involving other devices on the CAN bus; once I reset the STM32, the bug clears and I can't reproduce it without power-cycling the whole system.

I need to inspect the live state of the CAN peripheral (CAN->ESR, CAN->MSR — TEC, REC, LEC, BOFF) at the moment the bug is active, without disturbing it.

My setup:

STM32F205, Keil µVision project, debug build with -O0.
Segger J-Link, also tried Segger Ozone.

What I've tried:

Attaching from µVision starts a debug session but resets the target, which clears the bug.
Ozone's "Attach to running program" connects without reset and shows the device is running, but when I halt, I get no stack trace, no locals, no globals — only a raw PC value. I'm loading what I believe is the matching debug ELF; happy to double-check that the flashed image and the loaded ELF are byte-identical.

Questions:

My suspicion is the bug happens at the boundary of jumping from the bootloader to the application. Could it be the reason that Ozone is not fine with it?
Is there a known-good procedure in Keil µVision or Ozone to attach to a running Cortex-M3 without issuing a reset, and have full symbol/stack/local visibility?
If the flashed binary and the loaded ELF are from the same debug build, what else commonly prevents symbol resolution on attach? (CPU in a fault state? Stack corruption? Running from a region the debugger doesn't expect?)
As an alternative — would SWO/ITM/RTT printf or a RAM ring buffer dumped post-hoc be a more reliable way to capture peripheral register state at the moment of failure than live attach?

Thanks.