Hi guys,
First of all, thank you again for your time and your replies, I do appreciate them!

I rolled my codebase back to where I started the other day. Verified that it didn't misbehave (which it didn't) and started to reimplement the changes made.
I made small changes and verified between each one that it still worked as expected (and with worked I mean the issue with the DFLTCON register).

I'm now pretty much at the state I was in before and it's still working as expected. Obviously there is SOMETHING wrong with my "other" code but I have been unable to figure out what it is that makes it behave the way it does.

The biggest change implemented was to remove Darrels EE_Vars routine in favour for using "standard" DATA, READ, WRITE - this to save program space. I can not find any difference between the current implementation and what I used up until this morning. Yet, this works and the other doesn't.

pedja089,
Yes, thank you for your PM. Over the years I've tried to get MPLAB X going for the sole purpose of being able to do source level debug at the hardware level. Needless to say I haven't been able to get it going. This would have been THE PERFECT time to use it and I would still VERY MUCH like to be able to figure out what the heck is going on.

Richard,
I'm not using DT-Ints at all but of course you're correct. PBP uses it's system variables so if/when you use PBP in an ISR those system variables needs to be saved/restored which is what DT-INTS does (when declared as a PBP type interrupt).
The drawback is that it saves and restores ALL the system variables even though the code in the ISR might only use one or two. What I've done is to look at the generated assembly listing for the ISR and then added code to save and restore only those system variables that gets used by the PBP code actually IN the ISR. I'm fully aware of the "danger" in this, and any change to the ISR code will force me to again look at the generated .lst file to see if any more system variables needs to be handled. With that said, the interrupt code wasn't touched at all when the issue with DFLTCON being overwritten occured so I can't see how it may have anything to do with it.

I've got three interrupt sources and the code for each is very short and simple.
* My PCPWM timebase interrupt service routine does not use any PBP system variables.
* My QEI rollover interrupt service rouitne does not use any PBP system variables.
* My USART receive interrupt serive routine uses T1, FSR0H and FSR0L so I'm saving and restoring those (one WORD and two BYTE variables).

It's not something I recommend doing.

I have a feeling the problem is still hiding in there somewhere just waiting to re-surface when I least expect it. I'll make sure to keep you updated!

/Henrik.