article1 および article2 などのガイドラインに従って、lsass.exe
のメモリリークを追跡しようとしています。 lsass.exe
のgflagsを設定し、再起動したところ、プロセスID 804であることがわかりました。次に、コマンドラインを実行します。
umdh -p:804 -f:mylog.txt
これにより、すぐにエラーが返されます。
エラー:プロセスモジュールの列挙に失敗しました。
そして、ログファイルには何も役に立ちません。
//
// UMDH: version 6.2.9200.16384: Logtime 2013-05-16 14:49 - Machine=SHAUL-WORK-LT - > PID=804
//
// Debug privilege has been enabled.
// OS version 6.1 Service Pack 1
// Umdh OS version 6.2
//
// Preparing to dump heap allocations.
// Only allocations for which the heap manager collected a stack are dumped. Allocations whithout stack are ignored.
// The stack trace for an allocation is dumped as a list of addresses. They will be resolved to function names at compare time.
//
// Connecting to process 804 ...
// Process 804 opened handle=48.
ここからどこへ行くの?
UDMHのような低レベルのツールは、OSと密接に結合する傾向があります。あなたのUDMHは別のOSからのもののようです:
// OS version 6.1 Service Pack 1 <<<< 6.1 = Windows 7
// Umdh OS version 6.2 <<<< 6.2 = Windows 8
Windows 7(6.1.7600)に一致するUDMHを入手してみてください。
私が見る限り、Windows7のlsass.exeはメモリリークを起こしていません。
あなたが引用する記事はWindowsServer 2003/Vistaに関連しており、lsass.exeとcsrss.exeが狂ったようにメモリをリークし、ディスクにノンストップでアクセスしたため、Vistaがそのような失敗(または小さな成功)であった主な理由のいくつかがありましたWindows 7より)。これらのバグはWindows7で修正されました(ただし、Vistaでは修正されていません。理由は聞かないでください)。
お使いのバージョンのlsass.exeが大規模にメモリをリークする場合は、いくつかの有名なウイルス対策製品を使用してコンピュータを検証し、 sfc/scannow を実行します。
Umdhに関しては(lsass.exeをデバッグする必要がなくても)、最新の WindowsSDKおよびWindows用のデバッグツール がインストールされていることを確認してください。
Umdhがこの最新バージョンでまだ機能しない場合(またはWindows 7バージョンで@Jonathanが述べたように)、「管理者として実行」であるコマンドプロンプト(cmd)で実行する場合(管理者)の場合、Microsoftはlsassなどのシステムに不可欠なプロセスをトレースする機能をブロックしている可能性があります。
最後の試みは、 DevxExec ( download )の助けを借りて別の特権ユーザーアカウントを使用することかもしれません:
devxexec.exe /user:TrustedInstaller "umdh -p:804 -f:mylog.txt"
私があなたなら、私は次のことをします:
ここからProcessExplorerをダウンロードします http://technet.Microsoft.com/en-gb/sysinternals/bb896653.aspx
それを開き、lsass.exeを右クリックして、プロパティに移動します。 [スレッド]タブにジャンプして、CPU使用率が一貫しているスレッドがあるかどうかを確認し、[サービス]タブに移動して、認識できないサービスや、lsassを使用しているサードパーティのWindows関連以外のサービスがあるかどうかを確認して停止します。うまくいけば、それは問題の原因の方向にあなたを導くでしょう。