Nick:
Are any of your ISRs calling subroutines? Are the subroutines called also from other places?

Have you looked to see if the timer SFRs are not getting trounced on by some rogue code elsewhere that effectivly stops them or keeps them from getting reset properly for the next interrupt? Make sure to check all the timer specific control bits including the interrupt masks and enable bits.

Do you "accidently" have a stack imbalence problem wherein the RETI from the Timer ISR is somehow being missed under some oddball combination of interrupt latencies and overlaps?

Do you have global variables used in the ISRs that are also accessed in the mainline code or in other ISRs that have concurrency problems? (Ie one is being accessed while another access has left say an INT value half updated).

Do you have any SFR accesses going on that may have concurrency issues wherein the same SFRs may be accessed for read/writes/modifies by main line code and in ISRs?

Is a power cycle necessary to recover the supposedly "hung" timer interrupt?

Can you recover the hang via a simple pulse of the reset pin without having to recycle power?

Have you handled the WDT reset in a correct manner? Is there something wierd going on with that? I have had unexpected WDT activity bite my butt more times than I like to admit.

Any of these types of problems can require an ambitious effort to evaluate and make sure that it is not the source of a problem. It is easy to say that "the software is right" but hard to prove that it "IS Right" !!

Michael Karas