I have just replaced my computer after it was damaged with an upgraded machine I5 3.4ghz Quad core processor, 120gb SSD, 8gb of RAM and Windows 7 64 bit OS. Interface is a Focusrite Saffire Pro 40 Firewire.
The interface has worked perfectly in earlier versions of XP and 32bit Win 7 but now with all the increased resources father than any improvement im getting dropouts constantly. I have set the playback and resord buffers everywhere from 32 to 2048 and while the higher setting improve things im still getting dropouts. Enabling read/write caching doesnt seem to help.
 
Any help would be appreciated!

Have you tried adjusting the AUD.ini variable DropoutMsec to 500 or 750? Info about the variable here: http://www.cakewalk.com/D...I_Files.6.html#1134652
 
BTW, you are in the wrong forum. Although dropouts are common to all DAWs, the X series forum above this one is a more active forum for X series users.

Thanks I did as you suggested and am still getting pops and dropouts  though not as badly.
Should i repost in the other forum ?

Happy Thanksgiving!

Try latency monitor and post the results. Deferred procedure calls may be causing your dropouts and this app will finger the culprits.

http://www.resplendence.com/latencymon

Posting in the other thread will definitely get more eyes on the subject.

For now see if latencymon helps. Should have been the first thing to try. It may point to the true source of the problem rather than reducing SONAR's sensitivity to the problem (which is what my first post accomplishes). You can always mess with AUD.ini, the default is 250, should you want to restore it.

Results as requested
 
 
_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:01:30 (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: ROSS-WIN7
OS version: Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware: ASRock, H87 Performance
CPU: GenuineIntel Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
Logical processors: 4
Processor groups: 1
RAM: 8037 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 3399.0 MHz
Measured CPU speed: 3716.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.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 5827.301826
Average measured interrupt to process latency (µs): 3.759631
Highest measured interrupt to DPC latency (µs): 5812.841273
Average measured interrupt to DPC latency (µs): 2.114676

_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 561.024713
Driver with highest ISR routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Highest reported total ISR routine time (%): 0.515152
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in ISRs (%) 0.779185
ISR count (execution time <250 µs): 586759
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 4
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 574.060606
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Highest reported total DPC routine time (%): 1.072117
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in DPCs (%) 1.229656
DPC count (execution time <250 µs): 668021
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 3
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.
NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.
Process with highest pagefault count: msmpeng.exe
Total number of hard pagefaults 75
Hard pagefault count of hardest hit process: 66
Highest hard pagefault resolution time (µs): 2750.023242
Total time spent in hard pagefaults (%): 0.003891
Number of processes hit: 2

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 7.667463
CPU 0 ISR highest execution time (µs): 561.024713
CPU 0 ISR total execution time (s): 2.813230
CPU 0 ISR count: 586763
CPU 0 DPC highest execution time (µs): 574.060606
CPU 0 DPC total execution time (s): 4.411942
CPU 0 DPC count: 656465
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 2.452492
CPU 1 ISR highest execution time (µs): 0.0
CPU 1 ISR total execution time (s): 0.0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 37.323625
CPU 1 DPC total execution time (s): 0.005417
CPU 1 DPC count: 1739
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 1.895740
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 83.989114
CPU 2 DPC total execution time (s): 0.009995
CPU 2 DPC count: 3652
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 1.656066
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 35.305678
CPU 3 DPC total execution time (s): 0.012294
CPU 3 DPC count: 6168
_________________________________________________________________________________________________________

Wdf01000.sys is a generic library used by multiple drivers, so it's probably some driver or hardware device (a USB device or network card would top the list of suspects), not wdf010000.sys directly, that's the actual source of the excessive DPC latency. Try disabling your network and compare latencies, just because that's the easiest place to start. You can then start disabling USB ports in Device Manager, which might identify a faulty USB controller.

I am curious, is the conclusion
One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
significant or should the driver exploration start first. I don't know never having dealt with either.

CPU throttling for power conservation could be an issue, but rarely is. It's not a bad idea to have a separate power profile for recording sessions, though, in which nothing powers down. 
 
Looking over the OP's test results again, I see that it actually shows fairly modest DPC latency, maxing out at a mere half a millisecond with the vast majority of calls being less than a quarter-millisecond. Maybe not great results, but certainly not terrible. (I've seen latencies of up to 4 seconds caused by bad-behaved network adapters! That's terrible.)
 
I wonder if page faults might be a factor. It depends on whether they all occur initially when the project is first loaded (which is normal) or if they occur during playback/recording (which could indicate insufficient memory). It'd be worthwhile to check the task manager and see if any processes are eating unusually large amounts of memory. 
 
Another thought...if you are getting page faults while recording or playing back sample libraries you'll want to make sure your paging device (pagefile.sys) is not on the same physical drive as your audio files. I have mine split across two drives, with a third reserved just for audio.

could it be the fw chipset?