クラッシュレポート

アプリが思いがけず閉じたときにステーションが残すもの、何をいつ送り、いつたずねるか、そして開発版が持つ 2 つのデバッグのコマンドです。

クラッシュレポートは、設定のページの診断の組のただ 1 つの行です。クラッシュが、アプリが落ちていく途中で送られることは決してありません。ファイルに取り込まれ、次の起動がそれを送るか、あなたに見せてたずねます。この節は、そのどちらかを決める 1 つのスイッチを持ちます。このページには 設定の変更 の権限が要ります。

クラッシュレポートを自動で送信する

ランタイムが止まっている間、このページはそもそも描かれません（設定 を参照）。同じ申し出は同意のダイアログの中でも、「クラッシュレポートを常に自動で送信する」のチェックボックスとして差し出され、そこでチェックを入れると、このスイッチが入になります。スイッチの下でカードは述べます。「不具合の報告、改善の提案、ドライバーの要望はアカウントのページから行ってください。」そのフォームが フィードバック で、Ganter アカウントで送るからです。

レポートに何が入るか

処理されないエラーがアプリを落とすと、全体の受け止め役が 1 つのファイル、ステーションのデータの根の下の crash\pending-crash.json を書き、いちばん新しいクラッシュだけを保ちます。中身はこれです。

• アプリのバージョンと Windows のバージョン。
• そのエラーがどこで受け止められたか（Dispatcher、AppDomain、TaskScheduler、あるいは起動が終わりきらなかった場合は Startup）。
• 例外の型、そのメッセージ、内側の例外も含む完全なスタックの文。
• いちばん新しいログのファイルの最後の 60 行で、その障害に至る前後の様子です。
• それが起きた瞬間。

書かれる前に、Windows のユーザー名とプロファイルの経路は、現れるところすべてで <user> と <userprofile> に置き換えられます。この洗い落としは安全網であって、保証ではありません。自由に書かれたログの行はほかの名前を運びうるので、だからこそ、何かが外へ出る前にダイアログが中身の全体を見せます。

次の起動での同意のダイアログ

スイッチが切のとき、クラッシュのあと最初に画面が出る起動で、シェルの上に クラッシュレポートを送信しますか？ が開きます。「前回、Ganter Lab が予期せず終了しました。このレポートを送っていただくと修正に役立ちます。内容はエラーと、直近のログの短い抜粋です。送信する前に下でご確認ください。」クラッシュの詳細 の箱が、送られることになるものをそのまま見せ、コピー のボタンが同じ文をクリップボードに置くので（一瞬「コピーしました」と出ます）、それを検索したり、サポートに渡したりできます。クリップボードが受け付けなかったときは、ボタンが「コピーできませんでした」に変わります。コピーされていないものをコピーできたと思わずに済みますし、本文は画面に残るので手で選択できます。

通知領域に隠れた起動（Windows と一緒に起動する、または --tray での起動）では、ダイアログは出ません。レポートは次に画面が出る起動を待ちます。スイッチが入のときは、送信がダイアログなしで背後で行われ、ネットワークにつながっていなかったステーションはファイルを保って、次の起動でやり直します。

レポートは Ganter のサーバーのフィードバックのエンドポイントへ行きます。アカウント のページに Ganter アカウントがサインインしていればそれに帰属し、なければアカウントなしで受け取られます。ステーションから出るものはほかにありません。利用状況の遠隔測定はありません。

デバッグのコマンド

開発版のアプリは、スイッチの下に 2 つのボタンを持ちます。インストールされた製品版はどちらも持ちません。

この節がしないこと

ここにログを見る場所はありません。診断ログは イベント の、そのコンソールのタブに、詳細記録とサポートパッケージとともにあります。不具合の報告と要望は フィードバック です。クラッシュのファイルをアプリから編集することはできず、スイッチかダイアログの送信のどちらかなしに、アプリが何かを送ることは決してありません。