Dropout indicator not lighting up for buffer underruns

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.

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.

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.