書き込まれている内容だけからでは決定的な事はいえませんけれど、
解像度が変わってしまうくらいの挙動があるなら
グラフィックボードのドライバを疑いますね。
但し、よっぽど自分が書いたコードに自信が無いとそこまでは考えません。
まずは自分のコードに不具合があるのではないかと考えます。
何処まで異常な状況が起こるかはわかりませんけれど、
アプリケーション内でメモリの不正アクセスが行われると
状況によってはどんな異常な動作も起こりうると私は考えています。
ですから、まずは自分のソフトにメモリリークとか不正アクセスが
無いかどうかを調べます。
簡単なメモリリークならデバッグビルドしてデバッガーで動かし、
普通に終了すれば、アウトプットウインドウにメモリリークの表示が出ます。
また、本格的に調べたいのであれば、バウンダリチェッカとかピューリファイと
いった高価なソフトを使う手もあります。
不正アクセスについては、地道に追っかけるしかないですね。
不正アクセス即怪しい動作とはならない事もありますし。
怪しい動作が後になって現れるパターンもあります。
不正アクセスは前出のソフトでチェックする事も出来たと思います。

PATIOさん回答ありがとうございます。

メモリリークとかだけでなく、グラフィックボードのドライバってのもあるんですね。

コントロールの色の変更については、ある参考書のサンプルを元に、少々手を加えて、以下の様な
コードを書いています。

void ****::○○○○○()　//描画判断
{
　ー　途中省略　ー

　　if(*)
m_bDrive = TRUE;　　　←データをチェックして、描画状態のフラグを立ててます。
　　else
m_bDrive = FALSE;

　　m_cDrive.RedrawWindow(NULL,NULL,RDW_INVALIDATE | RDW_UPDATENOW | RDW_ERASE);

　－　省略　－
}

HBRUSH ***::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
　　HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
　－　途中省略　－

if(pWnd == &m_cDrive) //運転状態コントロール
{
　if(m_bDrive==TRUE && m_bStop==FALSE)
　{
pDC->SetTextColor(RGB(255,0,0));
m_cDrive.SetWindowText(運転中);
return ::CreateSolidBrush(RGB(0,255,0));
　}
　else if(m_bDrive==FALSE && m_bStop==TRUE)
　{
pDC->SetTextColor(RGB(0,0,0));
m_cDrive.SetWindowText(停止中);
return ::CreateSolidBrush(RGB(192,192,192));

　}
}
}

参考書の内容を完全に信じきってやるのもいけないのかもしれませんが、
ぱっと見た感じ、おかしなところがあれば、ご指摘願います。

OnCtlColorの中で、SetWindowTextを行うのはどうかと・・

しかし、それよりも悪いのは、
関数が呼ばれるたびに、CreateSolidBrushでブラシを作っているにも関わらず、
そのブラシを削除していないことでしょう。
確実にリソースリークになります。

PATIOさん回答ありがとうございます。

過去レスを探してみたら、PATIOさんの指摘同様に
「return::CreateSolidBrush（***）；はリソース不足になるのでしない方が良い。」
との記述がありました。

そこで、HBRUSH型の変数、例えば、”m_RED”を予め作っておいて、
「return　m_RED;」
の様に変更しようと思います。

文字の変更の方も修正して、連続動作させてみようと思います。

通常より負荷をかけて連続動作させていますが、
動作不良も起こさなくなりました。

以前の状態だとタスクマネージャーのプロセスタブでメモリ使用量を見ていると
どんどん増加していくのが見られましたが、

全く変動しなくなりました。

アドバイスどうもありがとうございました。