Ntdll.dll が原因のヒープ破損によりプログラムでアクセス違反が発生することがある。
参考( MSDN )：Ntdll.dll が原因のヒープ破損によりプログラムでアクセス違反が発生することがある.
ヒープ破損は、ヒープ ヘッダーが上書きされた場合または正しく設定されていない場合に発生します、とのこと。
ヒープ破損してる？
自作エクステに発生するエラーについて、このエラーはメモリ関連だけど動的確保の方法になにか問題あるかもしれない。
しかしオペレーティング システムのヒープ機能の競合状態によって発生する可能性がありますともあるので何かと競合してる場合もあるみたい。
しかし OS は XP でも 7 でもランダムに発生するため、およそこちらの仕込んだバグだとは思うのだけど怪しい箇所の位置特定がまだできない。
一応 ntdll.dll の動作は正常とみなし、自分が作ったバグとして対処方を探したほうが良さそう。
MS-IME、Atok-IME など IME と？関連？があるらしく、Google-IME ではエラーが出ないこともあるという報告もインターネット上であった。IME 関連で IME 変えると動作が改善するアプリがあるという報告例だけど IME、IME …
！？
DIME に Disable IME 機能つけてることを思い出した。
ネット上のエラー報告例だとアプリケーションがウィンドウ生成に失敗するケースがあるということで、つまりそれってウィンドウ生成時に IME.dll の読み込みをしなければ問題発生しないんじゃね的な。
ということはヒープの競合だった場合には、CF25 アプリの場合 DIME を使ってまず IME の読み込みをしないようにすれば少なくとも IME との競合は避けられる見通しである。
試してみた
DIME を使ってウィンドウ生成時に IME の読み込みを阻止してやったら動作改善した。
「お見事！」かと思ったが何度かループ処理させると結局クラッシュするようになってしまった。競合が原因だった場合たいへんめんどくさいけど、どうもこれは競合とかではなく自分で作ったバグみたいだ。
やっぱメモリ管理を見なおさないとダメかな。という結論に至った。
最終的に直せた
頻繁な alloc／realloc をしないようにもう少し大きめにメモリ確保したほうが良いのかもしれない、と思いやや大きめのサイズ指定をを心がけたら動作が一気に改善した。
参考：ヒープ領域と ntdll.dll について