(1)WinXP-Pro(32bit) Pentium-M(1GHz,シングルコア) MEM=1GB NIS2013-20.3.1.22
(2)WinVista-Ultimate(64bit) Xeon-X5460×2(3.16GHz、全8コア) MEM=64GB NIS2013-20.3.1.22
NIS2013を導入した(1)レガシーな32bit低速ノートPCと(2)大容量メモリー搭載64bitの超高速ワークステーションとを比較してみました。 両機とも5月度のOSのWindowsUpdate適用済み、NISは自動LiveUpdate設定です。 (1)の32bit機はパワーON後10分程度で平穏安定状態になりメモリー使用量は250MB程度とNIS2012より使用メモリーが少なく、NIS2012のときと同等な応答速度でアプリケーションを動かせます。 NISのLiveUpdate時には何の不具合もありません。
これに対し、(2)の64bit機では電源投入後、OSが立ち上がってからc:\ProgramData\Norton配下のファイルへのアクセスが続いており、平穏安定状態になるには2時間～3時間かかります。 NISはいったい何をしているのでしょうか。 加えて、shutdown時に電源が切れない(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3241)問題や、LiveUpdate後のエラーで以後のLiveUpdateが失敗しshutdown電源切断不可につながる(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3241)という問題があり、他にもMS-OfficeファイルScanが出来なくなったりします。 他のユーザーからも、Win-7/64bit、Win8/64bitでは不具合が多数報告されています。 また、NIS2012ではおきたことがありませんが、NIS2013に変えた後ではexplorerから動画ファイルを開こうとした際、「ファイルが見つかりません」と応答があり、しばらく待った後ではちゃんと同じファイルが開けるようになっていたことがありました。 別にアイドルスキャンが動いていたわけではなく、NIS2013を導入したというだけでファイルシステム操作のパフオーマンスが大きく阻害されているようです。 Vista-ultimate(64bit)ではccsvchst/Systemが各ドライブの管理ファイルをロックしている時間比率が余りにも高く、chkdsk*32の次回予約ですらロックが解除される時間帯を待たねばならないのでなかなか動けません。
こうなるともう32bitOS上のNIS2013と64bitOS上のNIS2013は別物として別けて考えなくてはなりません。
(1)(2)両機共にセキュリティの観点からCTRL+ALT+DELを押してユーザー名とパスワードの入力枠があるログオン画面を出して、ここにユーザー名とパスワードを入力してログオンするように設定しています。 低性能の(1)の場合、順序がわかりやすく、「ログオンするにはCTRL+ALT+DELを押してください」という画面(CTRL+ALT+DEL要請画面)が出てすぐにCTRL+ALT+DELを押してログオン画面を出してもすぐにはキーボード入力が受け付けられません。 結局はCTRL+ALT+DEL要請画面が出てから5分以上経過した時に受付可能になるようです。 受付可能になってからログオン画面を出してくれれば混乱しないのに。。。 NIS2012ではこのようなことは無く、ログオン画面表示直後から入力可能でしたが、NIS2012よりNIS2013が立ち上がり処理が重くなっていることは間違いないようです。 （ 他のユーザーからNISの製品アイコンの表示が遅いという投稿(http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/2141/page/2)がありましたが、やはり完全に立ち上がってから出してくれるほうがトラブルの種がなくなると思います。 ） 高性能の(2)では(1)と同じ状況なのかも知れませんが、高速に並行処理できますので入力に問題はありません。 不可解なのは低性能の(1)で10分程度で終わるものが、なぜ数段高性能な(2)で2時間以上もかかってしまうのかです。 確かに(2)ではWindowsSerchやシャドウコピーなどの立ち上げ時backgroundがあり、その分手間取ることになりますがNIS抜きで確認するとVista64自体は30分もあれば平穏安定になるのです。
現状で私は64bit機におけるshutdown不具合の原因推定の過程で以下の仮説を考えています。 NIS2013は立ち上がり時にパターンファイルデータベースとマシン上のユーザーのファイル群のスキャン履歴データベースの整合性チェックを行い、システム完全立ち上がり以後はユーザーのアプリ実行やLiveUpdateでのシンパターンファイルダウンロードによって都度これらデータベースを更新していって、且つこれらを参照してリアルタイム保護活動を行うが、Vista-ultimate(64bit)上ではこの初期の立ち上げ時の初期化処理が長時間を要した挙句、パターンファイルデータベース更新は成功するものの、スキャン履歴データベースは更新が失敗して終了し、データベース更新完了フラグは記録されない。 LiveUpdateでの新規パターンファイルダウンロード後の処理は(A)関連サービスの停止、(B)パターンファイルの更新、(C)サービスの再起動を行った後、パターンファイルデータベースの更新、パターン情報のスキャン履歴データベースへの反映処理を行うが、後者は失敗するものの、通常では前者は成功し、継続して新規LiveUpdateを受け取れる。 このとき、ccsvchstは「自殺可能」なので、shutdownでは正常に電源が切れるが、次回立ち上げた場合にはデータベース構築が最初からやり直しになるので、立ち上げるたびに毎回２～３時間ディスクアクセスが続くことになる。 32bitOS上では正常にデータベース構築されるので、次回からの立ち上がりも早いし、スキャンでの読み飛ばしなどが使えて、2012よりも快適に使えるのだが、64bitOS(少なくともVista-ultimate)上ではデータベース構築の毎回失敗によってデータベースの恩恵が受けられないだけでなく、システム安静までの完全立ち上がりに２～３時間かかってしまうという弊害が出ている。
何らかの要因でLiveUpdateの見かけ成功(上記(A)(B)(C)のみ正常終了)後にパターンファイルデータベース更新が失敗する場合は多分内部でループが発生していると思う。 このときにはパターンファイルデータベース更新処理が終わっていないので新規のLiveUpdateを受け取ることは出来ず、またループ発生によってccsvchstが「自殺不能」になっているので死ぬことが出来ず、shutdownは正常には完了しない。 「自殺不能」状態ではNortonFrameworkハングやOfficeファイルスキャン不能、メール受信不能のほか、Chatや電話相談時のNortonからの遠隔操作プログラムもインストールもできない事態になる。
shutdownで電源が落ちない事態になり、SW長押しで強制切断しても、次回立ち上げ時には「Windowsが正常終了しませんでした」という画面が出ることなく正常に立ち上がるのは、多分windowsの正常終了が記録された後の、shutdown最終段階でccsvchstが死ぬという順序になっていると思われる。 こう考えるとつじつまが合う。