プログラマ専用SNS ミクプラ

Microsoft visual c++ 2008を使っています。
あるプログラムを書いて、デバッグモードでコンパイルしたときは問題なく動作したんですが、
リリースモードでコンパイルして動かしたときに以下のエラーが発生して強制終了してしまいます。

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

色々ググったのですが、
ヒープを破壊？しているとかランタイムライブラリが入ってない？とかがヒットしたぐらいで、
直接解決に繋がる手がかりは得られませんでした

リリースモード時のデバッグの方法を良く知らないので完全にお手上げ状態です。
原因と思われるコード内で、どの部分でエラーが発生しているのか調べるために、
メッセージボックスを出力するコードを色々と挿入したりして調べてたんですが、
発生する場所もバラバラなので、これまた完全にお手上げ状態です。

諸事情の為、申し訳ございませんがプログラムのコードはお見せできません。
やってることとしては、メモリの確保やファイルへの書き込みを頻繁にやってるぐらいです。

こんな状況ですがこの問題を解決するために、有効な解決手段をご教授願います。

デバッグ嫌い さんが書きました:Microsoft visual c++ 2008を使っています。
あるプログラムを書いて、デバッグモードでコンパイルしたときは問題なく動作したんですが、
リリースモードでコンパイルして動かしたときに以下のエラーが発生して強制終了してしまいます。

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

色々ググったのですが、
ヒープを破壊？しているとかランタイムライブラリが入ってない？とかがヒットしたぐらいで、
直接解決に繋がる手がかりは得られませんでした

リリースモード時のデバッグの方法を良く知らないので完全にお手上げ状態です。
原因と思われるコード内で、どの部分でエラーが発生しているのか調べるために、
メッセージボックスを出力するコードを色々と挿入したりして調べてたんですが、
発生する場所もバラバラなので、これまた完全にお手上げ状態です。

諸事情の為、申し訳ございませんがプログラムのコードはお見せできません。
やってることとしては、メモリの確保やファイルへの書き込みを頻繁にやってるぐらいです。

こんな状況ですがこの問題を解決するために、有効な解決手段をご教授願います。

正直情報が少ないし、かといって情報を載せられないとのことですので、当てずっぽう的な見解の回答になりますがご了承ください。
まず、リリースモードでもデバッグ情報を生成すればデバッグ機能が使えます（VCは標準では生成されますが変更している場合は戻してください。）。
ですので、まず怪しそうなところの直前にブレークポイントを設置、F11キーでワンステップずつ実行してみてください。
＞発生する場所もバラバラなので
というのがよくわかりませんが、とりあえずこれで怪しいところを探すのはひとつの手段だと思います。

わたしはVC++2010しか使ったことが無いのですが、エラーが出た時に中断というボタンを押すとエラーの出た場所が表示されませんでしょうか？
もしそれが自分のコードでない場合でも、例えばそれがstd::vectorの中ならvectorを使っている箇所で何か問題を起こしている可能性があると推測できます。
このように可能性を絞っていく方法でもう少し粘ってください。

VC++からF5で起動したらエラートラップされませんか？
あとtry～catchをちゃんと入れていますでしょうか？

loweさん、ソフト屋さん、回答ありがとうございます！

すいません。言い方が悪かったです。
releaseモードでデバッグ実行できるのは知ってます。
でもその状態だと該当のエラーは発生しないんです。
リリースモードで、「デバッグなしで開始」、もしくはリリースビルドされた実行ファイルから実行した場合のみ、
該当のエラーが発生します。。


＞発生する場所もバラバラなので
＞というのがよくわかりませんが、とりあえずこれで怪しいところを探すのはひとつの手段だと思います。

例えばメッセージボックスをエラーが発生する前の箇所に置けば、そのメッセージボックスのメッセージが表示されるじゃないですか？
つまりエラーが発生している場所はそのメッセージボックスより後ろの部分になるということになりますよね？
こうやって地道に原因箇所を特定しようとしてるんですが、
ある場所にメッセージボックスのコードを書いてエラーが発生しなかったので、
さらにその位置を後ろにずらしていったんですが、結局エラーが発生しなかったので、
最初の位置にメッセージボックスのコードを書いて実行したら今度はエラーが発生してしまったんです。

だから結局どこの位置で発生しているのがわからなくてお手上げ状態というわけです。
「発生する場所もバラバラ」っていう表現はちょっと語弊がありましたね。すいません。

まだtry～catchは入れていません。
上記のような状態だったので、入れたとしても結局変わらないかと思ったからです。

もっと有効な方法ないでしょうか？

エラーはいつ起きるかわかりませんし、try～catch入れておいて
損はないと思いますよ。
あとはログをまずとるようにしてみるとかじゃないですか？
例えばVCなら下記関数
OutputDebugString( pStr );
でVCに出力できるので、これをラップするなりしてprint関数を自作して
そのprint関数にきた文字列をひたすらログファイルに出力するとかですかね。

これならVCでのデバッグ実行とか関係なくログはできるので、
あとはひたすら怪しいポイントに出力仕込んでいけば追っていけると思います。

余談ですが、fwriteはflose呼ばれるに落ちるとファイル書き出してくれないので
(もしかしたらflash的な関数呼べば書き込んでくれるかも？すいません、よく知りません)
::CreateFileとか途中で落ちても出力されるように工夫は必要ですが。

当該ダイアログが表示された際に、プロセスにアタッチしてみても分かりませんか？

＃ゲスパーですが、デバッグビルドされたdllとかを一緒に使っていたりしませんか？
----追記
＃もしくは/MTでビルドしたdllと/MDでビルドしたexeと使用している、とか。
＃VC++が入っている環境では動いて、入っていないまっさらな環境では動かない、ということとかありませんか？

＃あと、ソースコード示せなくても、現象が発生する実行環境の情報は書いてください。
＃コンパイルオプション、リンクオプション、モジュール構成等も、です。

デバッグ嫌い さんが書きました:loweさん、ソフト屋さん、回答ありがとうございます！

すいません。言い方が悪かったです。
releaseモードでデバッグ実行できるのは知ってます。
でもその状態だと該当のエラーは発生しないんです。
リリースモードで、「デバッグなしで開始」、もしくはリリースビルドされた実行ファイルから実行した場合のみ、
該当のエラーが発生します。。


＞発生する場所もバラバラなので
＞というのがよくわかりませんが、とりあえずこれで怪しいところを探すのはひとつの手段だと思います。

例えばメッセージボックスをエラーが発生する前の箇所に置けば、そのメッセージボックスのメッセージが表示されるじゃないですか？
つまりエラーが発生している場所はそのメッセージボックスより後ろの部分になるということになりますよね？
こうやって地道に原因箇所を特定しようとしてるんですが、
ある場所にメッセージボックスのコードを書いてエラーが発生しなかったので、
さらにその位置を後ろにずらしていったんですが、結局エラーが発生しなかったので、
最初の位置にメッセージボックスのコードを書いて実行したら今度はエラーが発生してしまったんです。

だから結局どこの位置で発生しているのがわからなくてお手上げ状態というわけです。
「発生する場所もバラバラ」っていう表現はちょっと語弊がありましたね。すいません。

まだtry～catchは入れていません。
上記のような状態だったので、入れたとしても結局変わらないかと思ったからです。

もっと有効な方法ないでしょうか？

メッセージボックスを使う方法は効率が悪すぎますし、関数の中までさぐれてないのではないですか？ブレークしてF11で一行づつ確認しながら全て実行してください。

デバッグ嫌い さんが書きました:ヒープを破壊？しているとかランタイムライブラリが入ってない？とかがヒットしたぐらいで、
直接解決に繋がる手がかりは得られませんでした

ヒープを破壊していないことは確認されたのですか？

ヒープを破壊するというのは動的確保したメモリの範囲外に書き込んだり解放済みのポインタを使って再び解放したりといったことです。
ヒープを破壊したときはCRTがメモリブロックの管理情報にアクセスしたときに落ちますから問題のある箇所とはまったく関係ないところで落ちます。
メモリの使用状況はプログラムを動かす度にも変化しますので再現性の低いバグの代表格です。

プログラムのいろいろなところで_heapchk関数を呼び出して戻り値を調べたら不具合が見付かるかもしれません。

リリースビルド後のバグ追求のためにtry～catchやら構造化例外処理やら埋め込めるものは埋め込んでおいたほうが良いと思います。
それとISLeさんの言われる通りヒープ管理情報の破壊は疑ってみて良いと思います。
ヒープ破壊だとウィンドウが出た時点でプロセスにアタッチしてデバッグしても原因が掴みづらいかもしれません。

こんな方法もあります。
「ヒープコラプションのデバッグ手順 ～ 例外 STATUS_HEAP_CORRUPTION (0xc0000374) - Web/DB プログラミング徹底解説」
http://keicode.com/debug/heap-corruption.php