NTUSER.DATファイルとUsrClass.datファイルが数千に及ぶため、なぜ削除できますか？
私のWebサーバーである2008 Xen VMが徐々に空き領域を失っていることに気づきました。通常の使用からではなく、調査することにしました。
2つの問題領域があります。
*C:\Users\Administrator\ (6,755.0 MB)*
with files:
NTUSER.DAT{randomness}.TMContainer'0000 randomness'.regtrans-ms
NTUSER.DAT{randomness}.TM.blf
[〜＃〜]および[〜＃〜]
C:\Users\Administrator\AppData\Local\Microsoft\Windows\ (6,743.8 MB)
with files
UsrClass.dat{randomness}.TMContainer'0000 randomness'.regtrans-ms
UsrClass.dat{randomness}.TM.blf
私が理解していることから、これらはレジストリ変更のインタイムバックアップです。その場合、10000以上の変更がある理由を理解できません。 （これは、フォルダーの場所ごとに存在するファイルの数であり、フォルダーごとに合計で20,000を超えます。）
ファイルは約15 GBのスペースを使用しているので、それらを削除したいのですが、削除してもいいのではないでしょうか。ただし、今後作成しないように、なぜ作成されているのかを理解する必要があります。
なぜそんなにたくさんあるのでしょうか？何が変更を行っているかを確認する方法はありますか？
- ログイン試行で作成されていますか？
- Webサーバーの毎日の使用に関連して作成されていますか？
- など
これらはレジストリ変更のバックアップではなく、実際には、レジストリへの変更になる前のレジストリへの変更です。ある種類の .tmp基本的に、レジストリ変更用のファイル。
Windowsではかなり一般的で非常に厄介な問題であったレジストリの破損に対する保護として、レジストリの変更が要求されたときに新しいバージョンのWindowsが行うことは、要求された変更をファイルに書き込んでから何かを行うことです。 （ユーザーHiveでの変更の場合、これらのファイルはNTUSER.DAT{GUID}.TMContainer####################.regtrans-ms、および順番に番号が付けられます-十分に前に戻ると、00000000000000000001ファイル。）レジストリに変更を書き込むことが「安全」であるとWindowsが判断すると、変更を行い、その後、変更が行われたことを確認します。変更が行われた時点で、ファイルを削除して移動します。他のOSタスクに。このプロセスで何かが失敗すると、これらのファイルが蓄積されます。
そして明らかに、あなたの場合、そのプロセスのどこかで何かが正しく機能していません。私はあなたがサーバーを通して見た場合かなりのペニーを賭けるでしょうEvent Logsこれについては、レジストリがロックされている、またはレジストリに変更を書き込めないというイベントの形で、大量のエラーが表示されます。 （おそらくUnable to open registry for writingまたはFailed to update system registry）。これらは、深刻な問題の兆候である可能性があります。または、いくつかのPITAプログラムが、起動するたびにレジストリに変更を書き込もうとし、権限がないことを示す可能性があります。
また、変更が書き込まれている可能性は低くなりますが、ファイルのロックハンドルが適切に終了されていない場合や、SYSTEMに書き込み権限がある場合など、ファイルを削除できません、ただしこれらのフォルダの場所に対する削除権限がありません。
ソースを追跡して、これらのファイルのmd5サム（または同様の）をすばやく実行して、それらがすべて、またはほとんど同じ（同じ変更がレジストリへの書き込みに何度も失敗していることを示す）かどうかを確認するのに役立ちます。または、重大な問題を示している可能性が高い多くのバリエーションがある場合-レジストリが多くのプロセスによって書き込めない、または問題のユーザープロファイルが破損している。
それらの分析が終了したら、これらの.blfまたは.regtrans-ms最後のシステムブートの前に作成されたファイルは安全に削除できます。それらがレジストリに書き込まれる（または行われる）方法はないため、ジャンクです。
何を作成しているのか、正確には何を作成しているのかは、ほとんど何でもかまわないため、自分で追跡する必要があります。サイトにアクセスするたびにWebコードの何かがレジストリの変更を書き込もうとしている可能性がありますが、アクセス許可がないために失敗します（確かによく見たことはありません）。ユーザーのログオンとその後のログオンによって生成された可能性があります。レジストリへの書き込みを試みてアクセス許可が欠如しているアクティビティ、および前述のように、それらは正常に作成および実行されているが、何らかの理由で意図したとおりに削除できない可能性さえあります。
すべてのログ、特にEvent LogsおよびIISレジストリ関連のエラーのログに記録して、それを絞り込み、何が原因かを突き止めます。