問題タブ [memory-dump]

C:\Windows\SysWOW64 に APPCRASH ダンプを生成するアプリケーションがあります (作成していません)。ダンプ中のアプリケーションは不自由ですが、データを失わないように最小限の容量で動作しています。問題は、これらのダンプが非常に大きいため、システムがこれらの書き込みにほとんどの時間を費やしており、アプリケーションの処理が大幅に遅れており、すぐにデータが失われ始めることです。

計画は、それを完全に無効にするか、RAM ドライブにマウントして、RAM ドライブにヒットしたらすぐにパージすることです。

今、私はこのキーの使用を検討しました:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx

ただし、元のダンプをリダイレクトするのではなく、2 番目のダンプを生成するだけです。

ダンプの名前は次のとおりです。

ダンプ-2013_03_31-15_23_55_772.dmp

これは一般的に Windows の開発者 (C/C++ のようなもの) の領域なので、私は彼らに連絡したいと思います。

さらに: ダンプ ファイルは循環していません (ハード ドライブに残っている 20 GB がいっぱいになります)。そのため、これが Windows の動作なのか、アプリのカスタム コードなのか (もしそうなら... ick!) はわかりません。

完全なメモリ ダンプがありますが、この例では、それに対応するユーザー スタック トレース データベースがありません。ダンプに対応する最新のシンボルと元のバイナリがあり、通常は使用できました。割り当ての!heap -p -a address時点でコール スタックを表示しますが、これはユーザー スタック トレース データベースなしでは機能しません。

私の質問は、このメモリリークの原因を突き止める別の方法 (直接的ではない方法ではありますが) があるかどうかです。

!heap -sこのヒープ サマリー ( )からわかるように、ヒープ00000000002e0000はかなり大きくなりました。詳しく調べると、データの 70% がサイズ 0x4058、0x23d1、および 0x10d1 のブロックに割り当てられていることがわかります (これは間違いなくある種のパターンです)。私はそれをさらに調査したいと確信しています。

私の問題は、ここからどこへ行くべきかわからないことです。以前はここにある指示に従って大成功を収めましたが、今回はユーザースタックトレースデータベースがなく、このパターンを簡単に再現できませんしかし、メモリダンプには多くの有用な情報が含まれていることは知っていますが、ここから意味のあるものを取得する方法がわかりません. Windbgの専門家？メモリ ダンプ アナリスト？ご意見をお聞かせください。

いくつかのブロック、最初の数バイト

TL;DR

WinDBGlmvが 2 つのバージョン情報フィールドを表示するのはなぜですか (私が知っている他のツールではこれを実行できないのに)、どのような状況でこれらのフィールドが異なる可能性がありますか?

背景: アプリケーションの (デッドロックからの) ライブ ダンプがあります。pdm.dllシンボルは正しく読み込まれ、デッドロックをマイクロソフト(vbscript エンジンに使用される「プロセス デバッグ マネージャー」)までさかのぼることができました。

次に、この DLL のどのバージョンが本番サイトのセッションでロードされたかを確認したいと思いました。

ご覧のとおり、ファイルと製品のバージョンが 2 回表示されていますが、ダンプでは一致していません。

実行中の iexplore プロセスの同じファイルをマシンでクロスチェックすると (明らかに、タイムスタンプとチェックサムが表示されます!)、次のようになります。

バージョン情報が一致します。

OS：Windows 7（Macは使用不可） iOS7搭載のAppleモバイル端末

アプリをテストしています。iOS6 以前のバージョンの iOS では、iTunes を使用して iOS デバイスを同期するだけで済み、アプリのクラッシュ ログとメモリ ダンプが「C:\Users\ * USERNAME \AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice」に表示されました。 \ * DEVICENAME " (ほとんどの場合、".crash" ファイルがありました)。しかし、iOS 7 にアップデートした後、iOS デバイスが同期されると、指定されたディレクトリにクラッシュ ログが表示されなくなります。クラッシュ ログはクラッシュの原因を知る上で非常に重要であるため、アプリがクラッシュしたらすぐに必要になります。クラッシュ ログを取得する方法について、ヘルプを提供してください。

編集：なぜあなたは反対票を投じているのですか？

または、Windows タスク マネージャーで同じメモリ ダンプを作成します。また、これらのプログラムがメモリ ダンプを作成する方法も興味深いものです。よろしくお願いします。

SSH経由でローカルマシンにログインし、シェルスクリプトを開始し、そのスクリプトからの出力をリアルタイムでブラウザーに出力するPHPアプリケーションがあります（ページの読み込みを維持することにより）。

ただし、シェルスクリプトがsudo service apache2 reload > /dev/null1024 バイトに達すると、一見ランダムなメモリがダンプされ、スクリプトが正常に終了するまで出力が中断されます。
接続が最終的に終了すると (たとえば、接続を強制終了することによって)、接続が開いたままになっている時間に応じて、追加の量のランダムなものが画面全体に吐き出されます。

実行中の PHP スクリプトは、何らかの中止/終了イベントが発生するまで、SSH 接続の stdout を読み取るだけです。それ以外は、ANSI カラー コードを HTML に変換します<span>。

すべてのセキュリティ関係者向け: PHP は、まさにそのコマンドに対してのみ "NOPASSWD" sudo を持つ通常のユーザーにログインしています。

私sudoのスクリプトは、正常に表示されていることを介して何が起こっているかを頻繁に出力するため、呼び出しが問題を引き起こしていることがわかりechoます。
また、リロードが失敗して実際に有用なエラーが吐き出された場合に備えて、stderr をパイプ処理したくありません。

関連するもののインストール済みバージョン:

• PHP 5.3.3-7+squeeze17 with Suhosin-Patch (cli) (built: Aug 23 2013 15:06:16)
  PHP 5.3 が必要です。レガシー アプリケーションは新しいバージョンを処理できないためです。
• libssh2-php0.11.0-2.1
• OpenSSL 1.0.1e-2+deb7u7( https://www.debian.org/security/2014/dsa-2896 )
• openssh サーバー1:6.0p1-4+deb7u1

この問題を修正して、ランダムメモリをダンプしないようにするにはどうすればよいですか?