Options for debugging MCU that is freezing/crashing (AVR32)
By adding your modifications to the interrupt routine you seem to have either exposed a race condition on the original code or created a new race condition. 

Writing re-entrant code can be tricky, writing re-entrant interrupt code is even trickier. Writing interruptible interrupt routines is fraught with perils. 

The fast interrupt was very likely intended to be fast, do its thing and get out of the way as soon as possible, leaving time for other things to happen. It is also likely to be high-priority interrupting everything that gets in its way and it’s likely to be consuming >5% of  all the executed instructions, by changing this code you made it increase that share.

You also state that communications are interrupt-driven, which suggest another time-critical decision. Some portions of this code is not likely to be very forgiving of increased delays in its execution. Your modification added the possibility of extra delays. 

By modifying the code and increasing the time the fast interrupt takes to complete. One or more of these conditions arose:


The time to execute the communications interrupt routine increased to the point its logic could not execute correctly. 
The communications interrupt routine was not able to finish before it interrupted itself, creating a reentrancy problem or simply overflowing the stack. 
You are modifying a register or flag in the fast interrupt routine that is not restored properly thus causing problems in the communications interrupts. 


For doing slow things, like blinking an LED, it’s really not a good idea to increase the execution time of something that is supposed to be fast.