「Process-Hucker」(http://sourceforge.net/projects/processhacker/?source=dlp)というユーティリティを管理者モードで実行して「Disk」タブを開けると、ディスクアクセスされている、全ファイルとI/Oを行うプロセスが表示できます(XP32の場合は「disk」タブは表示されない)。 これを使うとアイドルスキャンなどNIS2013の行状を細かく監視できます。 「scanを始める、止める」とはウィルススキャンのccsvchost.exeを生成／消滅することで、プロセス優先度を上げ下げすることとは違いますし、「スキャン」にはファイルのサイズ、日付、チェックサムを調べて前回検査時から変更されたかどうかを調べるステージと実際にファイルの中身をウィルス定義ファイルと照合して検査するステージがあると思いますが、後段ははccsvchost.exeですが、前段はccsvchostではなくてccsvchostから生成されたsvchostが担当しているようです。 スキーマーのsvchost.exeが1本常駐していて、後段のスキャンでは別途ccsvchost.exeが起動されるように診ました(手動スキャンでは明瞭)。 アイドルスキャン中に約10GBのファイルをシリンダーtoシリンダーでコピー(200MB/sec程度でexplorlerが元ファイルをread、書き込みはsystem任せ)しても、何食わぬ顔でアイドルスキャンは継続されており、スキャンの停止判断ではdiskのI/O速度は全く考慮されていないことが確認できました。 なんとか、NIS2014では直してもらいたいものです。
Dual-Xeon(QC)搭載win-Vista(64bit)のほぼ同一構成(me=16GB,32GB,64GB、disk=300GB(SAS)×4)のマシンが5台あり、すべてNIS2013を導入しています。 全機を約半日間アイドル状態にして観察すると、ディスクアクセスランプが1秒程度の間隔でON/OFFする状態になりますが、1台だけディスクアクセスランプが常時点灯のごとく高周波で点滅するものがありました。
超アイドル状態ではccsvchost.exeは1本だけ常駐しており、ccsvchostがsvchostを生成して種々ファイルの変更状態を調査し、スキャンを行うためのNISのデータベースを更新する動きをとっているように見えます。 特異な1台を調べてみると、C:\ProgramData\Norton\{番号}\NIS_20.1.1.2以下のファイルに頻繁に書き込み(読み込みではない)が行われていて、
svchost.exe(720) C:\ProgramData\Norton\{番号}\SRTSP\SrtETmp\xxxxx.TMP にも頻繁に書き込みが行われています。 システム保護のシャドウコピーを行うためしょうか、これらファイル、C:\$Mft、C:\$Logfile.C:\$BitmapもSystemプロセスで書き込まれています。 アクセスランプ点灯が数時間たっても止まらないことから、NISがNIS自身の自己修復を試みていて、なかなか完了できないように思えるのですが、NISを再インストールする以外に回避策はないのでしょうか？