報告、ないしはインシデントレポート。MSのIMEとなります。再現できませんでした。ボタンを押してみたら改善しないでしょうか。無いかを確認してみましょう。問題なのかの切り分けにはなるかもしれません。個ドラッグ&ドロップしてやってみましたが再現しません・・・というか、確定しないまま他のテキストボックスに移動できないのです。さんの手順で問題が再現しました。8453b506-1203-4250-a34c-439a250e8f77こんなようなものが記録されますので、バグ?と思っていました。この状況に悩まされていました。>魔界の仮面弁士さんご確認ありがとうございます。セットしたばかりPCでも発生しました。再現方法に不足があり申し訳ございません。クリックでフォーカス移動した際に発生します。>WebSurferさん再現テストしていただき、ありがとうございます。さんの手順で問題が再現しました。確定しただけでは止まりませんでした。確定した場合は停止することがありました。確定した場合は停止することがありました。ビルドの場合は停止していません。場合に再現しています。プロジェクトのプロパティの[アプリケーション]タブにあ「アセンブリ名」「ルート名前空間」のボックス間でテストした場合は問題ありませんでした。関数の内部実装が変更されたそうですが、関係あるのかな...。プロパティ画面では確かに死なないっすね。コード内が原因ではなさそう。0x000e34bb例外コードと例外オフセットは毎回同じ様子っす。今の時点でオイラたち「ユーザー」がいろいろ考えても無駄っぽい。インシデントレポート投げて終了っすね。魔界の仮面弁士さん色々とテストしていただきありがとうございます。長く困っていた部分ですので(バグとのことで解決には至りませんでしたが)とてもすっきりしました。掲示板で相談してよかったと思っています。ご助言いただきましたとおりMicrosoftForumsには書き込みをしてみました。※初めて書き込むので不慣れですが、何かフォローすべきことがあれば教えていただけますと幸いです。https://social.msdn.microsoft.com/Forums/ja-JP/c84d040b-b85b-4f85-a7d1-e76de274b8e5?forum=netfxgeneralja根本的な解決については、バクの解消となるかと思いますが、そちらはMicrosoftForumsで検討していきますが。(かなり昔から存在しているバグのようなので希望を薄く感じており)こちらの掲示板では回避を検討できないか考えておりますので、もう少しお付き合いいただけますと幸いです。回避策を2つ考えたのですが、もしもう少し工夫したほうが良いとか、このソースをもとに何か良いご意見いただけましたら幸いです。※今回の問題とは未関係ですが、2番の方法を応用するとOSの設定を変更しなくても、IMEモードを半角カタカナ等に変更できることがわかりました。1.少し原始的ですが、SendKeysでエスケープキーのキーイベントを送信する。FrameworkにてInputScopeを変更し、別のInputScopeとして認識させて変換中のテキストをキャンセルさせる。選択したところ今のところクラッシュしていないように見えます。軽減しただけなのか、解消したのか、それとも当方だけの現象なのかは定かではないですが。今のところクラッシュしていないように見えます。当方だけの現象なのかは定かではないですが。StadioチームじゃなくOSのチームの方がいいような気もします。例外スレッドのコールスタックを読み解けないので、追跡を断念。例外スレッドのコールスタックを読み解けないので、追跡を断念。64bit問題の可能性があるかもしれませんね。Win7で云々と記載した現象を試したのは32bitです。32bitアプリとしてコンパイル(最新のVSでそれができるか手元に環境がないのでわかりませんが)して、同じOS同じ.Netframeワークのバージョンで再現しなくなるなら、それがボトルネックである可能性が高くなります。64bitOS環境なのに、dll関係が32bitでないと動かないことが。SSISでOLEDBプロバイダー接続(accessに接続するときとか)でそんなことが起こりました。Officeは64bit版のままで問題なく、あくまでOLEDBプロバイダーが32bit版じゃなきゃだめ、要するにoffice自体は64bitでインストールし、Accessランタイムを32bit版で追加インストールすると動くようになる。確定した場合は停止することがありました。ビルドの場合は停止していません。場合に再現しています。この書込み見落としてました。するとこのケースは逆ですね。あるなら、リリース環境のOSがどうかによりますが、エンドユーザーの規約で「32bitじゃなきゃだめ」とかじゃなきゃ、x64ビルドにすりゃいいという話になりますね。64bit端末の方が主流ですからね。このソースをもとに何か良いご意見いただけましたら幸いです。変更できることがわかりました。1.少し原始的ですが、SendKeysでエスケープキーのキーイベントを送信する。変換中のテキストをキャンセルさせる。Sub上記の2者択一なら2の方がいいでしょうね。1の場合、Gotfocus発生の時点で未確定のテキストがどういう状態になっているか微妙な気がするので、エスケープキーによるキャンセルの発動により、よからぬ挙動が起こるリスクがあるような。2もKeyPresをハンドルするのはやめた方がいいと思いますよ。未確定のまま次の文字入れたら不安定な挙動をするような気がします。確かにエラーは発生しなくなりました。回避策3として追記したいと思います。追跡調査ありがとうございます。>大谷刑部ご助言ありがとうございます。ソースを工夫してみます。回避策の3と4を追記します。3.互換性モードを利用する。インストーラに組込む場合は、以下レジストリに追加する。※追加する値はテスト実行するなどして洗い出す。NT\CurrentVersion\AppCompatFlags\Layers4.Visualスタイルを無効化する。※いろいろ弊害がありそうですがプロジェクトのプロパティの[アプリケーション]タブにあるVisualスタイルのチェックを外す。回避策がたくさん出てきましたので、最後の書き込みから24時間がたちましたら解決済みフラグを付けたいと思いますがいかがでしょう。※特にご意見がなければクローズいたします。