2003はもう覚えてないけど…
「呼び出し履歴」か「コールスタック」みたいな名前の
デバッグ用ウインドウがあるからそれを開いてください
そこにそのエラーが発生した段階での呼び出し履歴がでるので
それを逆にたどってみてください。

その手のメモリエラーは、エラーが出てからでは後の祭り。
場所の特定など不可能です。例え特定できても原因まで遡るは人間にはムリかと。
そんなことは、神と呼ばれる人のみｗ

デバックでアプリを正常に終了させたとき、
Detected memory leaks!
Dumping objects ->

こんなメッセージでてませんか？
そのメッセージは、重要です無視しないように。
初めての方ってよくわからないメッセージを無視するからねぇ

履歴に出てないって書いてありましたね
さっきの書き込みは無視してください…

とーりすがりさん、+さん、レスありがとうございます。

> 「呼び出し履歴」か「コールスタック」みたいな名前の
> デバッグ用ウインドウがあるからそれを開いてください

質問に書きましたが、呼び出し履歴をみても、
アセンブラのアドレスしかありませんでしが。

> その手のメモリエラーは、エラーが出てからでは後の祭り。
> 場所の特定など不可能です。例え特定できても原因まで遡るは人間にはムリかと。
> そんなことは、神と呼ばれる人のみｗ

やっぱりそうですよね。。
7c841230()は、プログラムを中断させる命令の場所なので、
いつかどこかで何かやってしまっているのを見つける手段が
何かあればと思ったのですが。。
プログラムが膨大なもので。。。

> デバックでアプリを正常に終了させたとき、
> Detected memory leaks!
> Dumping objects ->

出ていませんです。

そうなるとそれこそTRACEとかOutputDebugStringとかの関数を使って
何処まで動いているのかを見るくらいしか手が無いかなぁ。
後は、ソースをどんどん削って行って問題が起こる最小限の状況を絞り込むか。
ただ、ソースを削り込んじゃうと不正アクセスをした後の動作が変わったりするので
なかなか一筋縄では行かないのですけれどね。

大体の検討がついたらひたすらソースを追いかけるしかないかもです。
ローカル変数の領域破壊から始まってシステム領域に飛び火なんて事もざらにありますか
らねぇ。

ＰＡＴＩＯさん、レスありがとうございます。

そうですよね。
ソースをどんどん削っていく方法で格闘してみます。

ちなみにRtlSizeHeap( 00150000, 055ABDE8 )の
「055ABDE8」はアドレスですが、
「00150000」にはどんな意味があるのかわかる方はいらっしゃいますか？

今回は必ず「00150000」ですが、
Webで調べると「00130000」や「00140000」があるようです。

今回発生した例外で、行おうとしていた操作などの
識別であればヒントになるかなと思っています。

WindowsXPのシンボル情報を入れると幸せになれるかも知れません。

Windows XP Service Pack 2 x86 retail symbols, all languages
http://msdl.microsoft.com/download/symbols/packages/windowsxp/WindowsXP-KB835935-SP2-Symbols.exe

ふーさん、レスありがとうございます。

面白そうですね。
来週試してみます。

> ちなみにRtlSizeHeap( 00150000, 055ABDE8 )の
> 「055ABDE8」はアドレスですが、
> 「00150000」にはどんな意味があるのかわかる方はいらっしゃいますか？
> 今回は必ず「00150000」ですが、
> Webで調べると「00130000」や「00140000」があるようです。

HeapHandleのようです。
GetProcessHeap()すると近い値が取れますし、
GetProcessHeaps()すると、おそらく含まれているかと…

瀬戸っぷさん、レスありがとうございます。

ソースを削っていったのですが、いつまでも発生するので、そのOCXのみを組み込んだ最
小限のものを作成して試してみたのですが、やっぱり発生しました。

ちょっと特殊な操作を伴うので、その再現方法をまとめてOCXベンダに報告することにし
ます。

みなさま、ありがとうございました。

解決です。