ユーザの書いたコードは一般的にアドレス0x00400000近辺にロードされます。
0x77f75a58はまず間違いなくWindows自体の中 kernel32.dll とかその辺。
可能性はいくつも考えられます
・あなたのコード中のバグをWindowsが検出して停止している
・暴走した結果たまたまそこでとまっているように見える
とりあえず「コールスタック」の表示で何か出ませんか？
出るならデバッグはまだ簡単。
出ないようならスタックを含めメモリを壊している可能性が極めて高い。

さっそくのお返事
ありがとうございます。
コールスタックは、
ハングした後でも表示されます。
NTDLL! 77f767cd()という箇所
（基本的には、エラー表示された、
ブレークポイントの設定位置と
言われている所と同じです）。
しかし、コールスタックでは、
どうも、ブレイクポイントは張れないようだし、
その後は、どうやって、
あたりをつけていけばいいか、
ご教授いただけないでしょうか？
ちなみに、ハングの場所は、
混合モードで見ると、
この77f767cdと言うアドレスの箇所は、
何の割り込みかはわからないのですが、
INT3になっている
（ret命令に挟まれていて、
その前が、call edxとなっています。
さらにその前も、
この長い機械語を前に前に追ってみてはいますが、
ソースとどう対応するのか？、
と言う感じです）
のと、パソコンによったは、
この種のハングの現状は、
出ません。

前レスを１００回くらい読み直して欲しいのですが 0x77f75a58 は
kernel32.dll (またはそれ以外の Microsoft の書いたコード) の一部です。
あなたの書いたコードではないのであなたのソースコードと対応するはずが無い。
INT3はブレークポイント命令です。それがkernel32中に置いてあるわけです。
つまり何らかの理由でkernel32がエラー検出してデバッガに処理を委ねている状況と推定
できます。
コールスタックに自作コードが表示されないのはスタックがぶっ飛んでいるから。
パソコンによっては出ない、ってのはごく普通の話でしょう。

バグによって致命傷を負った後、しばらく生きて動いていたけどついに力尽きたことを検
出した
というわけですね。
死亡地点はデバッガが通知してくれたわけなので、
犯行現場はあなたが推定するしかないです。

がんばれ

補足して書いておきますが、

まず、コールスタックに関してですが、
コールスタックは関数の呼び出し履歴を表示してくれます。
一番上が今いる位置で下に行けば行くほど呼び出し元に遡ります。
遡った結果、関数名が確認できるところまで行き着ければ、
ソースコードがある場所まで行き着けるでしょう。

あと、プログラムの不具合が原因でメモリ上の内容を破壊してしまった場合、
その後のプログラムの動作は全く予想不能になります。
壊しどころが悪ければ、直ぐにプログラムがハングアップするでしょうし、
偶々、壊した所が直ぐには使わないところだったりすると壊した後、
別の部分が実行されて壊した所を使うような状況になった時に
ハングアップする事もあります。
こうなってしまうとハングアップした時の状態を見て何処が悪さをしたのかを
想定するのはほぼ不可能です。
この場合は、ソースコードを一つ一つ追いかけてプログラムミスが無いかどうか
自分で検証するくらいしかありません。
ソースコードを確認する範囲を限定する為にプログラムを少しずつコメントアウトしながら
ビルドしては動かしをやってみる方法もありますが、この方法だとコメントアウトした事で
偶々動く状態になってしまう事もあるので結果を無条件に信用してしまうのは危険です。
なんにしてもメモリ破壊を起こすようなバグが一番厄介なので地道に調べるしかないですね。
一発で見つかる便利な方法なんて多分ありません。

プログラムバージョンの整合が取れてない場合にそういう意味不明な
現象が起きる場合もあります。
この手のことはちょくちょく自分のところでもあるのですが、
その場合は中間ファイルをすべて削除してリビルドすると直ります（笑）。

自作のDLL等使ってないですか？
自作のDLLがRELEASEでビルドされていて、
自作のDLLが原因でハングアップすると当然デバックしても
アセンブラのみの画面になってしまいます。

皆さん。
ありがとうございます。
自作のｄｌｌは使ってないのです。
中間ファイルをみんな消してからやっても、
同じ現象がおきます。

もう少し考えてみます。

デバッグモードでブレークポイントをずらしながら、
>ブレークポイントの設定位置　0x77f75a58
>と表示されて、止まってしまいます。
が何処で起きるか調べればだいたいのめぼしがつきませんか？