There is a huge clue in your report.  You have your CPU dynamically changing speed.  This is often the type of thing that can cause your problem.  You need to sort this out first.  As I have said previously in this thread, at the very least, you should go into advanced power settings and set the minimum processor state to 100%

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   3500.0 MHz
Measured CPU speed:                                   2843.0 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

There are also guides on the internet about disabling speed step, etc.

Some things need to be cleared up:
 
64bit (x64) Sonar/Windows/etc. is completely different from bit depth settings in Sonar - they have nothing to do with each other. The setting for the 64bit double precision mix engine just affects the precision with which Sonar carries out mixing calculations.
 
 
Render bit depth involves things like freezing or bouncing. Using 32 bit (floating point) here is useful mainly because it prevents clipping if something inadvertently went above 0dBFS. Other than that, it likely wouldn't matter much even if you set it to a low bit depth. If you are 1000% sure you will never clip anywhere at the track or bus level, 24 bit would be fine. Setting it to 64 bit rather than 32 bit doubles disk space and i/o but offers no advantages in return.
 
 
For 16bit (or lower) output, dither is a good thing. But at higher bit depths, the only reason to use it is a theoretical "best practice" to use dither whenever reducing bit depth. It won't make any audible difference at 24bit or higher bit depths, but it doesn't hurt either, so there's nothing wrong with turning it on if you like. But don't worry about it one way or the other.

Nicely put, drew.

I read beeps posts. I only bounce in real time if I'm using external FX. I never bounce in real time to help the dither.

Listen to Drew. He knows what's up and in fact is the guy who first told me about the internal bit depth stuff as opposed to project/hardware settings... even though I mangled the concept there. That pile of whargarble I put forth was more to warn you not to go messing up your tracks trying to get the bit depths down. On this topic I still really don't know WTF is going on which is why I just stick to standard procedures and default settings as much as possible.
 
As far as real time bounces I try to avoid fast bounce stuff whenever possible because I'd rather wait a little longer when bouncing than find an artifact later on even though my system SHOULD be able to handle most Fast Bounce stuff. That's probably just paranoia on my part but with my luck I prefer to err on the side of caution. ;-)

Daylaa
I hate to be the bearer of confusing news - but I have tonight attempted to reproduce the issue by changing the record and render settings back to '64' and then pushing up my sound card buffers to 1024.
 
The Pro Channel continued to operate seamlessly - whilst this sounds like a positive thing, it surely means that we haven't yet found the cause of the problem?
 
*Edit: I have experienced days of seamless Pro Channel operation before only to switch on another day to find the problem has returned.

I wouldn't be so ready to discount this as part of the issue (if not all).  Even though you were able to have things running seamlessly when you returned your settings to the non-optimal (or rather redundant) record bit settings, it's not conclusive that it wasn't the issue in the first place.  It might be that it takes a certain number of recorded tracks for the problem to resurface or a race condition where parts of your system are being more taxed.
 
Either way, I would definitely return to the settings recommended by Noel from Cakewalk, and enjoy using your system until the issue returns.  Hopefully it won't ever return...

gswitz
Yes. LatencyMon is good for all Windows Machines and it works the same. It is also good on x64 based OS Installs. It only takes 10 or 20 minutes from Install to report. Look for your top few offenders. As I reported above, my greatest latency is 0.17 milliseconds. If you get any over 0.5 you should be concerned and note the names of the DLLs and post them so you can be advised. Some of the DLLs will be familiar to the community and we can tell you exactly what is doing you in.
 
I remember one laptop I had where if I disabled the monitor driver, the monitor would still work on a generic driver but my dropouts stopped. It's these little things that the LatencyMon will point you to. If you know the DLL you're halfway home.

I hope I'm not hijacking the thread, but I've been able to fix my EQ sweeping dropouts using latencymon, as suggested by gswitz.  Thanks man!
 
Turns out the real-time anti-malware component of Microsoft Security Essentials (which I could have sworn I disabled) threw a hissy fit any time something in ProChannel was tweaked on the fly.  The offending process identified by latencymon was "MsMpEng.exe".
 
BitFlipper has posted a separate thread on how this process locked his system, so be careful out there boys and girls.

So... I'm guessing here... but I'll bet that the scanner wasn't causing a prob just when you twiddled the eq nobs. I think it was burning your processer every time you hit stop and it had new files to scan. It was checking them for issues and working your processor. The bigger the files, the longer it took.
 
When you messed with your FX, you just didn't have enough processor to spare for real-time audio. That's my bet.
 
I always turn off that scanner before a recording session. When I'm doing one track at a time (just me in my studio) it doesn't slow me down, but when I'm doing 8 or 16 and running for an hour before I hit stop... then it's an issue.

Hey folks I fully intend to reply in depth to your responses. At work now. Thanks so much.

Daylaa and OBHave,
 
If you are using windows 8,

• hit the Windows Button and type 'Scan for Malware'.
• Under the settings category, launch the scanner. It will begin to scan.
• Hit the Cancel Scan button.
• Click the Settings Tab.
• Uncheck Turn on real-time protection
• Click the Save Changes Button

If you do these things, when you hit stop within Sonar and the files are released, Windows will not try to scan them. Windows only scans them once, and it isn't normally too much overhead. The overhead point where it's a problem within Sonar will be different for different users. I can record 4-5 tracks at 24 bit 48 on my old laptop with no issues. When the count gets to 10, I can end up with dropouts when I record for a while, stop (closing the files) and immediately start recording again. The Windows Scanner will scan the large files and can be ungracious about its resource consumption. It will immediately start reading the 10 files from same drive I'm trying to write 10 new files to.
 
I normally leave Windows Defender checked and on, but I turn it off before big sessions. I have a DAW much like Daylaa's, built by Jim at Studio Cat (thanks Jim!!) and I have never actually encountered this problem on my current Daw.
 
Daylaa and OBHave, if you want to smoke this out, ensure you have Windows Defender enabled and bump up your File Bit Depth and start a new project and record 10 waves for an hour. Hit stop > then hit record again with ten tracks record-enabled and start twiddling your FX pots. See if that doesn't do you.
 
** The scanner is a double hit. It works your processer and reads from your drives. If you have lots of large files you are trying to write to the same drive that the scanner is trying to read from, it creates extra overhead. Interestingly, RME has a recorder that writes all the waves to a single file, making the task of thread switching easier for the PC. You can record with less overhead when all the tracks are written to a single file, but then there is additional overhead after the session when you have to split up the Waves. I haven't actually done a side-by side to get actual numbers of maximum tracks on the same PC using Sonar vs RME DigiCheck so it's possible they are equivalent. But I think DigiCheck can write more based on my load experience making recordings. I believe Windows Defender is multi-threaded meaning it will concurrently scan all 10 new files when you hit stop. If you use DigiCheck, there is only 1 new file to scan, if the scanner is enabled (granted it's much larger but a single thread will be created and the file will be scanned serially rather than all ten smaller files which are scanned concurrently creating extra concurrent load on the drive and processers).

Hi folks - so I've taken all of your suggestions and compiled a list of possible leads.
Beepster, Drewfx1, Silicon Audio, OBHave and Gswitz... you have collectively brought to me the following:
 
1) Try a USB interface. (This is definitely something I will try once I've eliminated everything else. My soundcard is solid enough in Home Studio which leads me to believe it is probably not the issue - but I won't discount it.)
2) Let my PC run for a while before opening Sonar. (This is something I will do from now on! I will admit to going straight into Sonar from the boot. But it's because my SSD is so lightening quick!)
3) Am I running RAID? (Hmm. Am I??? I don't fully understand RAID but I've certainly not intentionally set anything like this up. The harddrive I stream my audio to had some software to make it 'auto save/backup' everything but I disabled that?)
4) Windows Power Management/Advanced Power Settings - (I have just found that my minimum processor state is set at '5%'...is this a problem then??)
5) Run Process Explorer - (This I will do)
6) Ensure Microsoft Security Essentials is disabled properly (To my knowledge I've not done or installed anything to do with this. Will this automatically be on my Machine? I have Windows 7.)
 
I have forwarded all of your suggestions to RAIN computers management who have offered to remotely access my machine hopefully this week. I'm hoping they can try/comment on/eliminate some of your suggestions. A massive thank you to you all - I feel like we're getting closer to a fix. The problem continues to stay away at the moment, so it MAY WELL have been the render/record settings - however, I get the feeling there's still something holding my machine back. Hopefully, your suggestions are closing in on it.
 
I completely apologize for my obvious lack of computer/tech knowledge. I know how to use Sonar, just not the PC.
 
Regards,
Dave
 
(p.s - If you're in the UK like me, make sure you've tied your houses/belongings/fences/Grandmothers down in preparation for Sunday night/Monday morning. Gonna be breezy!)