0

HTML 編集機能を提供できるようにしたい WinForms アプリケーションがあります。そこで、Lutz Roeder の HTML Writerを C# から VB.NET に変換し、それを Windows フォームからカスタム ユーザー コントロールに変換しました。これは現在、MDI 子フォームでホストされています。

親 MDI を閉じるまではすべて問題なく動作しますが、親 MDI を閉じるとクラッシュし、例外をトラップできません。

エディター コントロールを、他に何もしない小さなバニラ WinForms アプリに分離し、問題が引き続き発生することを確認しました。

アンマネージ コードのデバッグもオンにしました (VS2010 を使用し、x86 および Framework 3.5 用にコンパイルしています)。得られるのは次のとおりです。

Windows has triggered a breakpoint in HtmlEditorMdi.exe.
This may be due to a corruption of the heap, which indicates a bug in HtmlEditorMdi.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while HtmlEditorMdi.exe has focus.
The output window may have more diagnostic information.

私が気付いた唯一のことは、エディターを含むフォームを開いた後、長い間隔を空けても、クラッシュしないことです。

私が本当に感謝しているのは、この問題を探す方法についてのアイデアです。もちろん、C# から VB への変換を間違えたのかもしれませんが、どこを見ればよいのかわかりません。

編集：

デバッガーをアタッチしてアプリを実行しましたが、何も役に立ちません。

Windows の「アプリケーションが動作を停止しました」というメッセージが表示され、問題の詳細に次のように表示されます。

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: HtmlEditorMdi.exe
  Application Version:  1.0.0.0
  Application Timestamp:    4cfb74c7
  Fault Module Name:    mscorwks.dll
  Fault Module Version: 2.0.50727.4952
  Fault Module Timestamp:   4bebd49a
  Exception Code:   c0000005
  Exception Offset: 000022b5
  OS Version:   6.1.7600.2.0.0.256.1
  Locale ID:    2057
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

アクセス違反であることがわかりますが、Debug > Exceptions > Win32 Exceptionsに移動してc0000005にチェックを入れても、壊れたときに何も役に立ちません-「利用可能なソースがありません」だけです。

4

2 に答える 2

1

引用した最初のメッセージは、内部ヒープ構造が破棄されたことを検出したときに、Windows ヒープ マネージャーによって生成されます。デバッガーが接続されていることがわかると、その診断が表示されます。2 番目に引用されたブロックは、診断をバイパスした場合 (デバッガーが接続されていない場合) に発生するもので、破損したヒープ内のメモリを解放しようとすると、ハードウェア例外が発生します。

ヒープ破損の問題は、診断が生成されるかなり前に実際の損傷が発生することです。[コール スタック] ウィンドウで、診断に至るまでのスタック トレースを確認できます。Microsoft シンボル サーバーを有効にして、Windows 関数の意味のあるシンボルを取得する必要があります。しかし、タイム マシンを必要とする、実際に損害を引き起こしたコードについては、有益なことは何もわかりません。

この種のヒープの破損は、常にアンマネージ コードが原因で発生します。AccessViolation 例外は、C/C++ プログラマーにとってよく知られた惨劇であり、マネージ コードが普及する大きな理由となっています。Lutz のソース コードはすべて管理されていますが、多くの P/Invoke および COM インターフェイス宣言が含まれています。それらをデバッグする良い方法はありません。ソース コードがありません。

これらの宣言を VB.NET に変換したときに、これらの宣言の 1 つが微妙に間違っていることは、これが発生する可能性のある 1 つの方法であることは間違いありません。また、バグは常にそこにあったのに、今その醜い頭をもたげたという可能性もあります。あなたはラッキーです。ところで、私はコードが 64 ビット クリーンだとは思わない。メインの EXE プロジェクトの場合: [プロジェクト] + [プロパティ]、[コンパイル] タブを下にスクロールし、[高度なコンパイル オプション]、[ターゲット CPU = x86] を選択します。これは、64 ビット バージョンの Windows で実行している場合にのみ関連します。

それ以外は、C# プロジェクトをそのまま使用することをお勧めします。ソリューションに言語を混在させることは、.NET で非常によくサポートされているシナリオです。

于 2010-12-05T14:19:03.013 に答える
0

windbgデバッガーは、この種の問題に対する「大砲」です。処理された例外などについて通知することで、手がかりが得られることがよくあります。唯一の問題は、使いにくく、学習曲線が非常に高いことです。

于 2010-12-05T15:15:19.350 に答える