0

.NET Compact Framework 3.5 アプリケーションからのランダム ネイティブ例外という質問に出くわし、ES400 と同じクラッシュ ダンプがありますが、解決策はかなり曖昧であり、Motorola ES400 デバイスでの最新のファームウェア更新の解決策の詳細と影響について明確にする必要があります。 2013 年 1 月 15 日にリリースされました。

この問題を要約すると、Motorola ES400 で実行されているコンパクト フレームワーク 3.5 アプリケーションは、ときどき、これまでのところ再現不可能なアクセス違反を奇妙な間隔でスローしています。有用な情報がかなり少なく、元の質問に対して見つかったものと同じクラッシュダンプを投稿できます。その答えは、システム状態情報の監視とUIの更新に関係しているように見えましたが、かなり具体的ではありませんでした。

私の質問は、この既知の問題に関連するシステム状態情報/制御操作は何ですか? 2013 年 1 月 15 日現在の最新のファームウェア リリースがインストールされている場合、ソリューションに違いはありますか?

これがまったく新しい質問として投稿されたことに腹を立てている人にはお詫びしますが、スタックオーバーフローは初めてなので、元の質問にはコメントできません。

4

1 に答える 1

0

問題のすべての呼び出しをtry..catchブロックでラップできますが、リソースとパフォーマンスが低下します。例外を避けることは常に良いことです。 例：Webサービスを呼び出す必要があります。Webサービス呼び出しの周りにtry / catchを配置するだけで済みますが、Webサービスホスティングサーバーに到達できるかどうかを事前に確認することもできます。

最初の試行として、try（Exception ex）..catch内のprogram.csでのみメインフォームの呼び出しをラップできます。未処理の例外はツリーのように処理され、処理されるまで上から下にバブルします（私の英語では申し訳ありません）。Exceptionクラスから取得できるすべての情報（Message、StackTrace、InnerExceptionなど）を使用します。これらの情報をファイルに書き込むと、後で確認できます。

一部のネイティブ例外はキャッチできません。私は、バーコードリーダーオブジェクトまたは他のデバイス固有の.NETラッパーオブジェクトと組み合わせてそのようなものを見てきました。このような不良オブジェクトに対する唯一の修正は、ラッパーのプログラマーと彼らが使用するネイティブコード/DLLによって行うことができます。例：itcscan.dllはバーコードリーダーにアクセスするためのC DLLであり、DataCollection.cf2.DLLはこのitcscan.dllの.NETラッパーです。itcscan.dllにネイティブ例外がある場合、.NETラッパーDLLとアプリケーションがクラッシュする可能性があります。自分で修正することはできません。新しいネイティブまたは.NETDLLをベンダーに依頼する必要があります。

ネイティブ例外のソースを見つける方法は？

コードを調べて、1つまたは他の呼び出しとテストを無効にすることを検討してください。すべての関数呼び出しと結果が書き留められるファイルへの適切なログ記録があります。おそらく、ネイティブ例外がスローされるパターンがログに見つかります。機能をどのように実現できるかを再考してください。あなたが言及した投稿のように、作者は彼のコードをイベント駆動型のアイコンのステータス更新から定期的な時間ベースのチェックに変更しました。

于 2013-03-09T07:20:21.297 に答える