I have a new MOTU 16A and it supports ultra low latency ASIO.  Of course I knew I wouldn't get the lowest setting possible because it's very resource intensive, and that's fine.  But I did notice in my testing that Sonar never lights up the Dropout indicator during recording when there is a buffer underrun.  You can definitely hear it, the sound is distorted / choppy in the recording, but there is no indicator
 
I can set the buffer higher and it sounds fine, but I'm more concerned about doing a bunch of recording, getting a few drops, and never even knowing it happened until I play back the clips hours later.
 
Is this right?  Does the dropout only work for playback and not recording?  If so, what is a solution for this?  I just want to know buffer underruns and dropouts reliably when they happen.

here's a bump,
to be honest im not sure, I've never had an issue with drop outs much
but if it were me, I would be more concerned about the underruns then I would be the light.
not being sarcastic either ;-)
your hard drive been defragged lately ?
have you tried adjusting the buffers ?
 
 
some tips here:
https://www.cakewalk.com/Documentation?product=SONAR%20X2&language=3&help=AudioPerformance.23.html
 
Go to Edit > Preferences > Audio - Sync and Caching and try different values for Playback I/O Buffer Size and Record I/O Buffer Size until you find values that works well for your particular hard disk:
              
The default value is 64. Try reducing this value, to 32, then 16. After each change, close the dialog box (click OK) and re-test your project's recording/playback behavior.

              
If problem(s) persist, try increasing this value, to 128, then 256, then 512. Again, close the dialog box and re-try your project after each change.

              
If you have an older, slower computer or an older, slower hard disk, you should try increasing the buffer size; decreasing is not advised on slower hardware. However, increasing this setting uses more of your computer's RAM. If you have a smaller amount of RAM in your computer, increasing the buffer size may not help.

If problem(s) persist, restore this value to its default and continue with the next step.
Mixing latency may be set too low
SONAR tries to send and receive audio data to/from your sound card with very a minimal delay (so that any real-time adjustments you make to a track's volume, pan, or other settings will take effect rapidly). If the latency setting is set too low, the sound card driver may not be able to keep up with the SONAR, and audio will be disrupted.
Try higher latency settings:
              
Go to Edit > Preferences > Audio - Driver Settings . Move the Mixing Latency Buffer Size slider control to the right in small increments until you see the value to the right of the slider increase; close the dialog box (click OK) and re-test your project after each increment.

              
If problem(s) continue, move the slider control back to its original position, and try increasing the number in the Buffers in Playback Queue textbox. (This value starts out at 4; try increasing it to 5, 6, 7, or 8). Close the dialog box (click OK) and re-test your project after each such change.

              
The total effective latency is displayed below the slider; it is determined by multiplying the per-buffer latency time (in msec) by the number of buffers in the playback queue.

So maybe I wasn't clear in my question.  I can easily solve the underrun by increasing the ASIO buffers.  I'm not having a persistent issue.  I'm concerned about the case sometime in the future when I'm running a lot of plugins or something and I have a singer here and I'm recording for hours and hours and hours.  Then after we wrap up and they leave, I go to listen to all the takes and I'm left with scratchy recordings because there was no indication anywhere that I was having an underrun issue - poof, my whole day was toast.
 
I'm trying to future proof that scenario.

I get plenty of stutters and underruns that Sonar doesn't catch. It used to do a better job of this back in the 8.5 days, but now, I can't rely on it at all and just have to listen carefully.

I don't know if this is applicable, but there is a DropoutMsec setting in the configuration file in preferences.
I don't exactly understand it, but I think it tells when Sonar will halt with a dropout indicator.
If anyone understands this better, I'd like to know more about it.
I have it set pretty high because I often experiment with very high load Reaktor ensembles that would otherwise halt Sonar with dropouts and I don't want that to happen when I do those tests.

There's an explanation of DropoutMsec here: http://www.cakewalk.com/Documentation?product=SONAR%20X3&language=3&help=INI_Files.6.html
 
But I don't understand what it's saying.  Is it an additional buffer?  Why would setting it to zero cause more dropouts if your goals is to not have any dropouts due to buffer issues?  I mean I guess the audio engine may not stop, but you have a crap recording full of clicks if it continues to truck along. lol.
 

Under high system load conditions, the SONAR audio pump mechanism may become starved. When this condition is detected, SONAR drops out. The DropoutMsec variable allows you to configure the tolerance time in milliseconds. This variable applies to all driver modes.
Setting DropoutMsec to a positive value > 0 specifies the actual time in milliseconds to tolerate before dropping out due to starvation.
Setting DropoutMsec to a negative value < 0 means we use a multiple of the audio buffer size as the tolerance. i.e. -2 means we use twice the audio buffer size.
Note that setting this value too low (e.g. 0) can result in more frequent dropouts in the program. If you notice too many dropouts, try raising it in buffer multiples or by explicitly specifying a millisecond value.