プログラマ向けのアプリケーション検証ツール：Windowsアプリケーションのテスト

おそらく、プロジェクトはメモリを操作する際の例外を回避するためにtry { /* code */ } catch (...) { }を作成せず、ハンドルを閉じてWindows Vista仮想化について知ることができ、プログラムはクラッシュしませんまれに繰り返される理由。

その後、運が良ければ、次のトピックに進むことができます。

しかし、時々、奇妙なことが起こりそうです。 プログラムは突然「クラッシュ」し、メモリがどこかでリークし、サーバーで実行されているプログラムの奇妙な動作について不平を言ってもう一度電話をかけましたが、もちろんあなたは問題を「ラップ」して、ハードウェアに依存していると確信していますそして大丈夫。 それでも、Windows用のプログラムの開発はしばしばトリッキーであり、不注意またはアーキテクチャの無知によるエラーから誰も安全ではありません。 私はこれらの間違いを避ける方法を学びません-私は自分自身を知りません。 しかし、ここで効果的なデバッグのための1つのツールをアドバイスできます。

これは、Microsoft Application Verifierについてのものです。 しかし、これはデバッガーではありません。 それどころか、デバッガーがなければ、それ自体は比較的役に立たない。 しかし、それと組み合わせて、多くの重要なプラットフォーム固有の問題を検出できます。 さらに、AppVerifierを使用したテストに合格しない限り、「Windows 7と互換性がありません」証明書を取得することはできません（実際には「Vista Certified」でも同様ですが、明らかにこれは受け入れられません）。 そして、この証明書は、ユーザーに対して、それを受け取ったプログラムがより良くならないかもしれないことを保証しますが、少なくともそれは傷つけません 。 さて、「水」は終わりました。仕事に取り掛かりましょう。

申し込み方法

Habrocheloveka用AppVerifierをダウンロードしてインストールしてください。複雑ではありません。 グラフィカルシェルを実行してみましょう（実際の管理者の下から、Vistaの下で、それは別の方法では機能しません）。



左側には、テスト用のアプリケーションのリストがあります。 右側には、選択したアプリケーションをチェックするセクションのリストがあります。 MSDNは、AppVerifierはC ++プログラムをテストするように設計されているが、一般にネイティブコードに適用可能であると主張しています。

グラフィカルシェルはテストを生成せず、目的の項目を選択することのみを可能にします。 チェック自体は、いわゆる「レイヤー」、動的に接続されたライブラリvfbasics, vfcompat, vfLuaPriv, vfprintおかげで実装されます（ system32それらを鑑賞できsystem32 ）。 テスト対象のアプリケーションが起動すると、アプリケーションに接続し、 HeapAlloc, GetTickCount, CloseHandleなどのシステム関数の呼び出しをインターセプトします。 インターセプターはいくつかの追加チェックを実行し、元の関数を呼び出します。したがって、 以下で検討するいくつかのケースを除き 、これはテスト対象のアプリケーションの動作に影響しません。 パフォーマンスの低下が顕著でない限り。 主観的に、最悪の場合、プログラムは5回「スローダウン」します。特定の数値が必要かどうかは、あなたに任せます。

ここには重要な機能があります ：テスト中のアプリケーションのファイルを追加するときに選択するという事実にもかかわらず、チェックはパスなしでその名前にのみ添付されます 。 プロジェクトを収集する構成（およびフォルダー）を心配する必要はありません（通常、デバッグとリリースのフォルダーは異なります）が、インストールされたチェックを忘れることができます。また、デスクトップからプログラムを起動すると、動作していません。」

テスト項目の意味については後ほど説明しますが、次に、たとえばnotepad.exeを追加して、すべてのDawをインストールします。 ノートブックを実行し、数行を追加して、保存してみてください。 O-pa、失敗：



状況の唯一の結果ではなく、別の警告ウィンドウが表示されるか、まったく表示されない場合があります。 どうしたの？ AppVerifierグラフィックアドインをもう一度見てみましょう。 今回は、メインメニューから[ログ]項目を選択します。テストされたアプリケーションに関連付けられたログファイルのリストを参照してください。 起動ログによる。



物理的に、これらのログファイルはユーザープロファイルのルートにあるAppVerifierLogsフォルダーにあります。 素手（バイナリ形式）でそれらを読むのは難しいので、対応するログの[表示]ボタンを押します。 それをxmlにダンプし、xmlのデフォルトビューアーを開きます。



注意深く見た人のために：このスクリーンショットに表示されるエラーは、前のスクリーンショットのエラーメッセージ（プログラムの通常の動作）に対応していませんが、少し遅れて発生します。

問題の簡単な説明とスタックトレースを次に示します。 そして、私からは、警告ではなくエラーを探す方法のヒントがあります。 ちなみに、エラーが存在する場合、プログラムはVista / Win7との互換性の認定を受けません。 待ってください、でもこれはノートですか？！ まあ、はい、唯一のシッ。

患者の治療

デバッガーを実行します。 スタジオに組み込まれたデバッガー、またはDebugging Tools for Windowsの無料のWinDbgとします（確かにもっと洗練されていますが、今では重要ではありません）。

そして、ここに私たちの患者がいます：

int _tmain( int argc, _TCHAR* argv[])
{
int *p = new int ();
delete p;
*p = 0; // p = 0 will be OK, but *p = 0 is error!
}

このフラグメントの潜在的な危険性は、 deleteとメモリの上書きを伴う行が時間とともに引き伸ばされたかどうかを簡単に評価できます。 ただし、リリースでもリリースアセンブリでも、このような問題は検出されません（Visual Studio、既定の構成）。

ここで、Application VerifierのBasicsグループをテストするためのプログラムを追加します。 そして、デバッガーの下で（たとえば、F5のスタジオから）実行します。 AppVerifierはスタジオの声で私たちに話しました：



また、デバッグ出力には、対応する構造的な例外が表示されます。

=======================================
VERIFIER STOP 00000013: pid 0xB54: First chance access violation for current stack trace.

02B59FF8 : Invalid address causing the exception.
0082142F : Code address executing the invalid access.
0013F670 : Exception record.
0013F68C : Context record.

=======================================


例外が何であるか（00000013）、どのメモリアドレス（02B59FF8）、どのコードアドレス（0082142F）で発生したかがわかります。 Windowsデバッグシンボルをダウンロードした幸運な人は、問題が発生したソースコード内の場所と例外につながったスタックトレースも表示されます。

さて、私たちはこの問題を発見しました。つまり、修正したということです。 他のエラークラスの場合、操作アルゴリズムは保持されますが、修正手順はそれほど簡単ではない場合があります。

検出可能な問題

ここで、AppVerifierがどの問題を識別できるのかを考えてみましょう。 すべてのテストオプションはグループに分けられます。 低リソースシミュレーショングループとTimeRollOverおよびHighVersionLieテストを除き、チェックはアプリケーションの動作を変更しません（エラーが検出されない場合）。

1.歪みのチェック

1.1。 低リソースシミュレーション

ここがノートブックの落下の理由です。 このグループのテストでは、リソース不足のシステムの動作をシミュレートできます。 アプリケーションは、メモリ割り当て、ファイル作成、イベント、ウィンドウ、およびレジストリエントリを簡単に拒否できます（乱数センサーを使用）。 通常、約2〜5秒の「穏やかな」時間があり、アプリケーションがリソースを完全に使用できるようになります。 これは、アプリケーションが起動できるようにするために行われます（以前に発明されたもので、以前は悲しいものでした）。 プログラムの通常の動作は安定性です。 警告ダイアログを表示しますが、「クラッシュ」は表示しません。 そのため、コードではこれらの状況を提供する必要があります。

1.2。 グループMiscのTimeRollOver

action数回実行する1秒以内のコード例を考えてみましょう。

DWORD time_end = GetTickCount() + 1000; // 1s timelimit
do { action(); } while (GetTickCount() < time_end);

キャッチは肉眼で見ることができます。 time_end非常に近いが、 DWORD_MAX-1000未満であり、 action() 1秒以上かかる場合がある場合、サイクルは希望より少し長くなります。 つまり、50日間（DWORD_MAX /（1000 * 60 * 24））。

そして、これはあなたが次のフラグメントについて言う唯一のケースではありませんか？

char buf[8];
sprintf(buf, "%i" , GetTickCount());

このような問題を診断するには、TimeRollOverをチェックすると、GetTickCount（）関数の値がより速く「実行」されます。 ゼロ調整の前の完全なサイクルには5分かかります。

1.3。 互換性グループのHighVersionLie

突然GetVersionEx関数を使用する場合、このテストは、有効なOSバージョンの検証が正しくないコードブランチの検出に役立ちます。

OSVERSIONINFO osvi;
ZeroMemory(&osvi, sizeof (OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
GetVersionEx(&osvi);

BOOL bIsWindowsXP_or_Later = (osvi.dwMajorVersion >= 5) && (osvi.dwMinorVersion >= 1);
if (!bIsWindowsXP_or_Later)
printf( "Windows XP or later required.\n" );



この箇所には明らかな間違いがあります。 Windows 2000（5.0）を遮断するために、マイナーバージョンXP（5.1）に追加のチェックが導入されましたが、コードはWindows Vista（6.0）も破棄します。 Windows 7（6.1）では動作します。 これが本当にWindows Vistaとの互換性が低い理由ですか？ Microsoftは、この問題を含め、Vistaプログラムとの互換性のない70％が機能しないと主張しています 。

しかし、開発者のコ​​ンピューターでこの状況を診断することは困難です。彼は、OSの1つの修正バージョンを持っています。 OSの異なるバージョンで仮想マシンを使用することも、DAWのHighVersionLieを使用することもできます。 次に、 GetVersionExの値が変更されます（通常、ルールdwMajorVersion += 3; dwMinorVersion = 0 ）。

2.変更しないチェック

2.1。 基本グループのメモリ

HeapAlloc, GlobalAllocおよびその他のWindowsヒープマネージャーAPIへの呼び出しを検証します。 彼はメモリリークを監視していませんが、これは他の方法で解決できます 。

2.2。 基本グループのTLS

スレッドローカルストレージAPIへの呼び出しの正確さを監視します。

2.3。 基本グループの例外

例外をキャッチすることの適切性を監視します。特に、アクセス違反例外、 try { } catch (...) { }などのスタブ内の例外を「マスク解除」しようとする試みを監視します。

2.4。 Basicsグループのハンドル

ハンドルに対する操作の許容性、ハンドルの正確性、およびその寿命を監視します。 もう少し英語で 。

2.5。 [基本]グループのロック

クリティカルセクションの正しい使用をチェックし、クリティカルセクション設定に関連する別のストリームからのクリティカルセクションのドロップを許可しません。

2.6。 バンドMiscのDirtyStacks

スタックの未使用部分を0xCDパターンで定期的に埋めます。これにより、初期化されていない変数または関数パラメーターを検出できます。

2.7。 MiscグループのDangerousAPI

TerminateThreadような望ましくない、潜在的に危険なAPI関数の使用について通知します。

2.8。 ルアプリフ

限定ユーザーアカウント特権テスト。 プログラムに管理者特権が必要かどうかを確認し、プログラムは実際の管理者だけに有効なアクションを実行します。

予測（管理者のみが実行できるすべてのプログラムアクションを一覧表示する）と診断（ ACCESS_DENIEDエラーで管理アクションでプログラムを拒否する）の2つの部分で構成されます。 したがって、プログラマはゲストとしてログインしてプログラムを個別にテストする必要はありません。 また、Windows Vista以降での仮想化に関連する多くの機能もチェックします。

おわりに

AppVerifierは、多くの「フローティング」および「隠された」（および場合によっては特別に隠された）問題を特定して解決できる興味深いツールです。 全体として使用することは難しくありません。特定のスキルがあると便利です。 また、「Windows互換」の証明書を受け取りたい場合、それを知っていることは避けられません。 私はすでに2つのプロジェクトを手伝いましたが、あなたにとっても役に立つことを願っています。

*すべてのソースコードは、 ソースコードハイライターで強調表示されました。