Hi Noel,
I'm still on Sonar Producer 8.5.3 and I'm also getting these messages (for ages now) using my Fireface UFX (via USB) and before that with a FF800 (via Firewire). At least it's not specific to Sonar's X-series or to the type of connection. I've really given up on finding a solution but when I saw this thread I thought I'd chime in. It mostly happens, when Sonar has to change sample rates because another program had changed it.
For example, Sound Forge always defaults to 44.1 kHz. When Sound Forge is opened while Sonar is running at a different SR this message pops up. Sound Forge also seems to have a higher priority for SR changes than Sonar, because there's no way to set it back while Sound Forge is still open.
Another example: in my case, Sonar's SR for new audio projects is set to 88.2 kHz. If, for whatever reason, the system's SR is set differently when Sonar opens, it literally takes ages before playback starts, then it drops out and said message appears. HTH

Thanks. As described there is nothing that SONAR can do to prevent that behavior since the RME driver manages its state when same rates are changed by internally unloading and reloading its kernel mode components. I would argue that the message is somewhat useful since its telling you what happened, since without it you would never know why SONAR dropped out or took long. The whole purpose of the device change notifications that we added was to allow SONAR to detect device removal and allow SONAR to re-detect the new configuration dynamically. 
 
I'll see if I can repro the second case. AFIK I did not run into that.

Noel, If these units truly disconnected, wouldn't there be an issue with replying NO? I thought you may have eluded to that earlier.
 
I am still having a hard time understanding how this can be a hardware issue when multiple devices with different protocols have the same disconnect message issue. the constant is SONAR and RME, but the most constant is SONAR.

...

Not if the driver reloads itself as they do when the sample rate changes.
I'm not sure what else I can contribute to this since you seem to have a hard time accepting the facts despite me explaining this multiple times. The same thing will happen in another host except for the message of course.
 

Guitarmech111
Noel, If these units truly disconnected, wouldn't there be an issue with replying NO? I thought you may have eluded to that earlier.
 
I am still having a hard time understanding how this can be a hardware issue when multiple devices with different protocols have the same disconnect message issue. the constant is SONAR and RME, but the most constant is SONAR.

I confess the level of knowledge here is now considerably in excess to the capacity of my brain.
Suffice it to say, am extremely glad the OP got sorted.
My similar sitch I confess seems presently ameliorated...either by random physical wigglings of my fw PCIe card molexes or my 17 times bitten, 18 times shy recent Dim Pro experiences resulting in me getting Kompakt to work, of all things..
   An odd piece of other randomness came up in my thrashings about for personal solutions: I was at the stage of throwing in the fw towel and simply grabbing the drivers to allow my Delta 66 to work, when I noticed way down in the drivers' small print that "several Avid users have reported that with W7 64 SP1(sic?), their Delta 66 will disconnect" after approximately 30 minutes....
  The "workaround" seeemingly is to shut down their DAW(presumably PT), then fire it up again.
Now, I know jack about the arcane mysteries of Windows, but I'm furrowing my brow just wondering if there are some oddities with W7 and how it manages its audio, that given the right(ie, wrong) conditions, present similar "disconnect" scenarios.
  I'm not wishing a reply particularly, as I realise this thread may have run its effective course.
[I'm also maybe teetering on the edge of biting my own head off, as W7 will both allow me to burn a CD, and rip back what it burnt...yet refuses to play the very CD its been successfully mauling about, whining about a flippin' codec for doing so....so please ignore me, as I've a nervous breakdown to return to...]

Noel Borthwick [Cakewalk]
Not if the driver reloads itself as they do when the sample rate changes.
I'm not sure what else I can contribute to this since you seem to have a hard time accepting the facts despite me explaining this multiple times. The same thing will happen in another host except for the message of course.
 

Guitarmech111
Noel, If these units truly disconnected, wouldn't there be an issue with replying NO? I thought you may have eluded to that earlier.
 
I am still having a hard time understanding how this can be a hardware issue when multiple devices with different protocols have the same disconnect message issue. the constant is SONAR and RME, but the most constant is SONAR.

As I have stated a few times already, I would be happy NOT seeing the message if the sample rate changes. That would be a start.

I was going to suggest that maybe other hosts handle the message invisibly: eg. they do the equivalent of pressing "no" after a short delay if they receive this message, and only fail if this doesn't work.  Would that be an option for SONAR?

Other hosts do nothing so if the device is really disconnected you are on your own with no warning.
We'll see if the sensing behavior can be improved in the future.

The great Jazz Musician, Noel B.!!
We'll see if the sensing behavior can be improved in the future.

Nice one, Noel! Thanks for being open to ideas.