choinga
Another issue I have is that anytime I use or enable a 64 bit engine (on export for example or in the device preferences to use the 64 bit engine) I get this weird high pitch buzzing in the background.  As soon as I uncheck the box - it goes away.
 
Thanks in advance!

Are you using X3D?  That's supposed to solve the problem with the 64 bit double precision engine.  I feel for you because I get these messages, too, and though they don't stop production, they're annoying.

...well, it was looking pretty good there for awhile.  Had a loop running for about 20 minutes without the audio dropping out...but alas, eventually it did.  
 
I literally have everything turned off on my machine.  Windows Defender disabled/service shut off, internet adapter disabled, all the Intel tools that get installed/video tool that all run in the tray I disabled them in task manager/startup.  Literally the only things running in task manager were system stuff that I can't do anything with, sonar and RME.
 
Power management set to high perf, no screen saver, don't turn the disks off.  WU done - latest 8.1 drivers/updates installed.  Sonar is set to not share the driver with anything else so not sure what else could be 'stealing' it.  I did notice when switching cables around that the error I see randomly is exactly the same error I see when I unplug the FW cable.  So, it seems that in some way Sonar or RME see's a physical disconnect in some way?  
 
I don't know what else to do, if anything.  Clearly something is wrong here.  I pointed the RME support guy (Jeff - seems like he's the only one in the US?) to this thread when I emailed him so if/when he ever returns my email/call he has some insight into what's going on and that there are multiple others dealing with the same issue.
 
Certainly if I or we ever resolve this I'll share back on this thread.  My guess is it's a driver issue.  The latest firmware I see for the FF800 is pretty old but the driver is very new - as in a few weeks old.  So, maybe they fixed a few things and broke some others with this latest driver release...who knows.

Please consult your windows event viewer for errors.
Thanks.

Late to the party here and of no practical use except to testify occasional but annoying replications of exactly the same as the OP: (Motu 4Pre firewire on a TI chipset PCIe with latest 64-bit drivers, W7Pro64(SP1), Sonar x3 Producer 64bit(d),.
    My present personal experience is that I'm more likely to trigger the FW interface's thowing-in of its towel by periods of cycling through Dimension Pro progs. I've no idea if this of universal significance.
 I've presently got a headscratching list of other odd behaviours(now including my own as well as those of the trio of X3, W7, and the Motu )...thus, my present, though head-in-a-bucket "workaround", is plenty of saves, close X3 when the Motu quits, turn off Motu, turn on Motu, fire up X3 and rock+roll.
  (Turning off my firewire device whilst  Sonar is running, even when X3 informs me my device is no longer available, then turning the FW on again, has no effect).
 I have little knowledge and even less time, so as to presently allow me to do an Enterprise-Picardian level 3 diagnostic of all variables in W7, X3 and my Motu FW...I'm merely chipping in to say that a) I do feel your pain, as my experience tallies with yours; b) my feeling is that this is not an RME-specific error; c)my wild, wild and supernatural guess is that there is still some default W7 desire to attempt to wrestle back default audio control from a firewire device to the onboard audio...but of course this doesn't explain random behaviour(in my case) of soundcard hari-kiri whenever I get crazy with Dimentia Pro.

Noel Borthwick [Cakewalk]
SONAR listens to device change notification messages from Windows. These indicate when audio devices are added or removed from the system. For device removal specifically we listed to the DBT_DEVICEREMOVECOMPLETE event. If this is being triggered, it means that something caused the low level WDM driver to send this event to Windows. Most typically this could be caused by a faulty connector (USB or firewire) or a bad controller. If its happening on a good system then it could be a fault in the driver that is generating this message.
What happens if you ignore the message - does the audio continue to work? If not then it was really disconnected from the system somehow...

My system goes on without issue when I hit NO

well, PreSonus StudioOne at least went about an hour last night before I decided to hit the rack.  I came down this AM though and the transport was stopped so at some point RME threw up.  No error messages though with the PreSonus app so no telling what happened - however, I can attest at this point that my system is pretty screwed up.  
 
I went over to simply restart the transport on StudioOne and got a Windows error popup titled "RME FireFace Firmware Mismatch".  The error says:
 
This driver version requires at least firmware revision 2.77.  Please download the latest flash update tool from RME's website to update your FireFace.
 
Um, I have 2.77 "Hardware Version" and the very latest FF800 driver off their site.  I saw this a couple times randomly with Sonar too when I was having audio error problems.
 
Anyway, my system is kinda hosed now.  Without rebooting I tried to restart StudioOne and got a hardware error on their startup screen (kinda scrolls through what's loading/going on...different than Sonar) and even after rebooting everytime I go into StudioOne nothing works and I get that RME Firmware error popping up all the time.
 
Sadly, even when I go into Sonar, the transport plays but I can't hear anything...the lights on my UA 2192 aren't coming on (output meter) so even though Sonar says there's activity on the master fader pushing to the RME, nothing is making it via ADAT over to my 2192.
 
*SIGH*
 
So, seems to me like RME has some work to do as well.
 
I don't know - for those of you that have systems that work properly can you keep a project looping for hours and hours on end without the transport stopping?  Just trying to determine if my 'test' holds any water.

I have a very simple project - one track with me talking into a mic for about 30 seconds...no FX...and then just looping it.  So, it's not hurting anything - barely even get a blip on any resource usage, etc...
 
I had never tried looping something for hours before even when things were working well so no idea what the expected behavior might be.  But I do know in this case that something went haywire after letting it run for quite some time...I'm going to have to try to uninstall/reinstall RME drivers or something - nothing works at this point and of course the RME drivers in the tray show that everything is working great.  RME Mixer shows signal, etc... but nothing works in the DAW's.  UGH.

Noel Borthwick [Cakewalk]
All SONAR is doing is reporting the message that a device was inserted or removed. This is not new - this feature was added way back in SONAR 8.5. See the topic Change I/O devices without restarting SONAR in the notes. So either some operation is causing the device to really disconnect or the message is being sent at the wrong time.
If ignoring the message causes lost audio to the device then its really disconnected somehow.

I remember getting this msg and reporting it with my FF800 quite a while ago. It may have even been in the 8.5 cycle. This still persists with my UFX and brand new cables, motherboard and all. 
 
There are a few of us that have not really had a disconnect Noel. How would Cakewalk prefer to proceed with the msg being sent at the wrong time or if it should have been sent at all? Or is this an issue to pursue for Cakewalk? It is an annoyance, but not a showstopper for me since replying no basically clears the msg and audio continues.
It is clear we are talking about someone who does likely have an issue with their system(OP) as well as the other issue where the msg may not be issued correctly.

Ken, list your recipe for the SONAR looping. As long as it is documented, we can all follow it the same way. Do you have a large region looping? how many measures? Is it midi and audio? Any FX? Did I miss something? I have time and will try to help get it repro'd.

I started a loop of 8 measures at 12:05 with my UFX. This has midi, audio and FX in it. I will let it run for 30 mins or so. If no issue, I will get a vanilla setup like you have and give it a go.
 
btw, what state are you in? I am also in CST.

I have used FF800 - sometimes two units at a time - from the first days FF800 was released. One unit worked absolutely perfectly in XP & SONAR 8.3.1 and 8.5. Windows 7 + X1 was OK, too, but Windows 7 + SONAR X2 began to show this message. I failed to locate problem or fix it and I purchased RME UFX which works perfectly in USB mode.
I believe problem is either in RME or Windows Firewire driver. My troubleshooting included replacement of motherboard, 1394 card (3-5 different ones from several brands, with and without TI chipset), cables, going back to legacy driver, totally new PC and upgraded SONAR version. RME support did their best to help me solve this issue but they were unable to find the ultimate answer.
 
Interesting enough, disconnecting never happened when playing music with Winamp or Media Player - only in SONAR in ASIO mode.

...mine has been 2 hours now in StudioOne with no drops.  Going to switch over to SONAR now and see how long it goes...

Not for me.  I keep my 2192 at 44.1, the RME driver at 44.1 and SONAR at 44.1.  I never change that and don't have any projects at different sample rates that I have to change.  So, I don't think that's my issue but could be for some other folks.
 
For the record, I started up a SONAR session with the 1 track/loop thing at 12:25 CST and it's been running for 25 minutes now without crashing.  That's definitely a record.  It will eventually though but the problem is that it will eventually come during a project and it always happens at the worst time...like right in the middle of the best take. :)
 
I'm going to have to bang on it later tonight like I'm actually doing some work and see how long it makes it.  I'm going to let it run and see how long it goes.

choinga
For the record, I started up a SONAR session with the 1 track/loop thing at 12:25 CST and it's been running for 25 minutes now without crashing.  That's definitely a record.  It will eventually though but the problem is that it will eventually come during a project and it always happens at the worst time...like right in the middle of the best take. :)

 
That sucks. Its definitely not normal for it to happen while you are recording and nothing else is using the hardware.
As I mentioned earlier SONAR just displays the message but takes no action unless you respond to the message with yes. If you are actually losing audio when that happens it might indicate a hardware problem (especially if others are not seeing that). I suggest working with RME support on that angle. I'll see if anyone can reproduce that issue here.

So all you are doing is looping in SONAR and no other apps running? Do you get a dropout message before that or just the device disconnected message?
Also after the message is audio playback dead - how do you recover at that point?