それ自体が落ちた、またはコロボックが調査をリードする

そのため、アプリケーションをデプロイし、適切で経験豊富な開発者として、クラッシュレポーターを挿入することを忘れませんでした。 最初のレポートを取得し、スタックを開き、周囲を見て、再現を試み、中断し、「これを何と言いましたか？」という質問をします。 しかし、それはどうして起こったのでしょうか？」アプリケーションがクラッシュするために、ユーザーは何をしましたか？



そして、ここでアプリケーションのデバッグログ、または少なくとも開いた最後のユーザーアクションのログ、突かれた場所など。 さらに、WinFormsアプリケーションでユーザーアクションのログを記録し、このログをクラッシュレポートに含めることに焦点を当てます。



最初に思い浮かぶのは、単純なアプローチです。各ユーザーアクションのハンドラーを入力し、ログにエントリを追加します。 しかし、これは膨大な作業と馬鹿げたコードです。 さて、内部のすべての人に必要なイベントをサブスクライブする基本的なフォーム/コントロールを実行できますか？ ああ、コントロールは追加と削除ができるようになり、リークリークアプリケーションとこれらすべてがコードのために一緒に遅くなります。 しかし、基本的なフォームなしでのみ同じことを書き、フォームの変更を追跡し、多数のイベントをサブスクライブし、それでもスローダウンしませんか？



フックの前にすべてがすでに発明されていることがわかりました！ しかし、すみません、これはどのようなWinFormsなのですか、それは同じWin32 APIなのですか？！ そして、 あなたは何を生きたいですか-あなたは腕を使い果たしたり、行きませんか？



そのため、ユーザーがアプリケーションをあふれさせるために行ったことに興味があります。 つまり、マウスを使ってどこでどのように突っ込んだか、どのキーを押したのか、何を入力したのか、どのウィンドウを開いたのか、フォーカスがどのように移動したのかなどです。 開始するには十分です。



マウスフックは、 通常のマウスと低レベルのマウスを担当します 。 キーボードの場合、それぞれキーボード、 通常および低レベル 。 1つのアプリケーションのみで入力を監視する必要があるため、おそらく、低レベルのグローバルフックは多すぎます。





そして、通常のフックで十分なので、すぐにメッセージフックに掛けることができます。1つのボトルにマウスとキーボードがあります。 ウィンドウのアクティブ化とフォーカスの移動は、 CBTフックで簡単に捕捉できます。



掘る場所は明確です





Hrenak、hrenak、そして生産中！ ええ、shchazz、これは.NET、ベイビーです。 CallNextHookEx呼び出しの直後に、フックが1〜2サブスクリプション/サブスクライブ解除された後、すぐではありません。 宙ぶらりんのポインターがあることは直感的に明らかですが、コードをざっと見てみるとわかりませんが、なぜですか？ SetWindowsHookExを注意深く見てみましょう。 2番目のパラメーターは、ハンドラー関数へのポインターです。 つまり、ハンドラーのアドレスは、C＃の観点ではIntPtrになります。 Soooo、HookProc lpfnをIntPtr lpfnに置き換えるとどうなりますか？ 次に、 マーシャルを使用する必要があります。 GetFunctionPointerForDelegateを使用して、デリゲートからアドレスを取得します。 元のコードを見ます-デリゲートを明示的に作成しません。 ilspyの助けを借りて見ます：

 SetWindowsHookEx(3, new HookProc(Win32HookManagerBase.GetMsgProc), IntPtr.Zero, threadId);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トナカイです！ 構文糖衣、ありがとう、私たちから重要なものを隠しました-アンマネージコードに正常に渡されるアドレスを含む中間デリゲートオブジェクトが作成されます。 その後、デリゲートオブジェクトはガベージコレクターによって正常に処理され、どこにも制御を移そうとするとアンマネージコードがクラッシュし始めます。



OK、デリゲートを明示的に保存します。

 static HookProc procGetMsg = Win32HookManager.GetMsgProc; static HookProc procCbt = Win32HookManager.CbtProc; SetWindowsHookEx(WH_GETMESSAGE, procGetMsg, IntPtr.Zero, threadId); SetWindowsHookEx(WH_CBT, procCbt, IntPtr.Zero, threadId);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイル、チェック-動作します。



彼らは戦いの半分を行い、イベントの通知を受け取ることを学びました。 次に、イベントをわかりやすく人間が読める形式で表示できるようにする情報を収集して記録する必要があります。



例を挙げる





次に、ユーザーアクションの記録をオンにして、ボタンのいずれかのハンドラーにアプリケーションをドロップする単純なアプリケーションを作成し、「再生の手順」を含むクラッシュレポートがシステムに送信されるようにします。

 static void Main() { LogifyAlert client = LogifyAlert.Instance; client.ApiKey = "<my-api-key>"; client.CollectBreadcrumbs = true; client.StartExceptionsHandling(); // etc } void showMessageButton_Click(object sender, EventArgs e) { MessageBox.Show(this, "text"); } void crashMeButton_ClickEvent(object sender, EventArgs e) { object o = null; o.ToString(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバー側では、収集された情報に基づいて、次のようなユーザーアクションの説明を生成します。

 string GenerateMouseEventMessage(Breadcrumb breadcrumb) { return GetBreadcrumbCustomField(breadcrumb, "mouseButton") + " mouse button" + GetBreadcrumbCustomField(breadcrumb, "action"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

送られたメモを開いて確認します 。







何も明確ではないことは明らかです。 はい、ユーザーはマウスでつついていますが、正確にはどこですか？ そして、記録も送信もしませんでした。 マウスメッセージについて興味深い点は何ですか？ ああ、 hWnd 、必要なもの。

 [DllImport("user32.dll")] static extern int GetWindowText(IntPtr hWnd, StringBuilder lpString, int nMaxCount); string GetWindowText(ref Message m) { StringBuilder windowText = new StringBuilder(1024); GetWindowText(m.Hwnd, windowText, 1024); return windowText.ToString(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時に、ユーザーが押したキーをログに入力します。







新しいクラッシュレポートを再構築、実行、生成、監視します。







もう悪くない。 そして、キーストロークは適切に思えたので、パスワードの収集を開始できます。 鳥といえば、パスワード。 ユーザーの明示的な同意なしに個人情報を送信することはおそらく良くありません。 たぶん





ここで、IsPasswordBoxメソッドを実装する必要があります。これは非常に優れたものになります。 通常の入力フィールドとパスワード入力フィールドの違いは何ですか？ もう一度、メモリの深さからWinAPIのメモリを思い出します。ここでそのような例を見つけます。 これから、ゼロ以外のパスワードcharを持つES_PASSWORDスタイルの編集コントロールが必要であることがわかり ます 。 私たちは実現します：

 [DllImport("USER32.dll")] static extern int GetWindowLong(IntPtr hwnd, int flags); [DllImport("USER32.dll")] static extern int SendMessage(IntPtr hWnd, int Msg, IntPtr wParam, IntPtr lParam); static bool IsPasswordBox(IntPtr hWnd) { const int ES_PASSWORD = 32; int style = GetWindowLong(hWnd, GWL_STYLE); if ((style & ES_PASSWORD) == 0) return false; int result = SendMessage(hWnd, EM_GETPASSWORDCHAR, IntPtr.Zero, IntPtr.Zero); return result != 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

取得するもの：







ボタンと入力フィールドを使用すると、すべてがうまく機能します。 そして、パズルを複雑にしたら？ 複雑なコントロール、グリッド、リボンを備えたデモアプリケーションに統合します。







実行し、グリッド内のリボンのボタンをつついて、結果を確認します。







悲しい光景。 リボン全体にhWndが1つだけあり、グリッドに2つ、グリッド自体に1つ、アクティブなエディターに1つがあります。 そして、私たちはこのすべての善で何をすべきでしょうか？ 特定のコントロールのギブレットを掘り下げることは選択肢ではありません。異なるベンダーからのそれらが多すぎるため、内部は非常に定期的に変化する可能性があります。 セクション508を思い出し、それが何であり、何と一緒に食べられるのかを調べ始めます。 その結果、 IAccessibleについて学び、しばらくしてAccessibleObjectFromWindowメソッドとAccessibleObjectFromPointメソッドについて学びます。 最初の方法はキーボードイベントに最適で、2番目の方法はマウスイベントに最適です。





それは技術の問題です。 ゼロ以外のIAccessibleを取得した場合、 AccessibleRoleを分析し、必要に応じてコントロールとその親のaccNameを記述します。





次に、サーバー部分を終了して、次の図を取得します。







それははるかに有益になり、各レコードがどのコントロール（またはその一部）に属するかは非常に明確です。 すでに動作することは可能ですが、今は同じユーザーアクションをもっとコンパクトな形式で見たいと思いました。 さらに、私たちは従事します。



PS：



→WinFormsクライアントのソース



興味のある方は、プロジェクトのウェブサイトとドキュメントを ご覧ください 。

こちらのHabréのLogifyに関する紹介記事もご覧ください。

他のプラットフォームでのユーザーアクティビティのコレクション： WPF 、 JavaScript、ASP.NET