Dual-Xeon(QC)搭載win-Vista-ultimate(64bit)＋NIS2013のほぼ同一構成(me=16GB,32GB,64GB、disk=300GB(SAS)×4)のマシンが5台あります。 尚、全マシンについて、自動LiveUpdateは生かし、リアルタイム保護は有効にしていますが、パフォーマンス維持のため、NIS設定でのアイドル時最適化(OSのdfrg.exe)は殺して、Vistaのdefrag自動起動機能についてもレジストリ設定でEnableAutoLayout=0とし、BootTime_Optimizationも殺して、dfrg.exeは自動起動しないようにしています。 このマシン群でshutdown時に電源がちゃんと切れたり、切れずに無限待ちになって長押し電源遮断せざるを得なくなったりする問題にずっと悩まされています。 長押し強制電源off後は、立ち上げなおしてから全diskの「chkdsk /F」を予約設定して2回のreboot(C：のchkdsk実施後、自動rebootしてD：E：Fをチェック)を経て、マシンを立ち上げなければならず、1時間程度の時間ロス(chkdsk設定に長時間が必要)が出るので。困ってしまうのです。 この状況は http://communityjp.norton.com/t5/forums/forumtopicpage/board-id/NIS_NAV/thread-id/3241 に報告しているように観察を続けてきましたが、さらに観察を続けた結果、この場合には必ずshutdownで電源が落ちなくなるという十分条件が判明しました。
shutdown使用とする直前にNISの設定画面を開いてLiveUpdateの前回実行時刻表示を他のマシンの同時期のそれと比べたとき、他のマシンのそれが数分前の表示であるにもかかわらず、当該マシンの前回実行時刻表示が他より異常に長い数十分あるいは数時間であるとき（異常時）は、そのマシンをshutdownすると、必ず電源が落ちません。 通常の場合、手動でLiveupdateを実行して更新があった場合は、LiveUpdate終了時に前回実行表示が更新されて、「2秒前」とか「3秒前」に変化するのですが、「異常時」では数件のダウンロードと更新が報告されても「前回実行時刻」は不変であるケースが殆どです。 再度の手動LiveUpdateを実行すると、赤色で「作業中」が出て、前回のLiveupdateが失敗した旨の表示が出る場合が多いようです。 「異常時」からの手動Liveupdateで「前回実行時刻」が「数秒前」に更新される場合でも、shutdown時には必ず電源が切れない「無限地獄」になります。 加えて、全ての場合ではありませんが「異常時」に設定変更しようとして「設定」をクリックすると、「SymantecFrameNetworkが応答しません」と報告される場合があり、この時電子メール受信やExcelシートスキャンなどは失敗します。 重大なのは、この「異常」の発生は設定画面を開いて見なければ発見できないことです。 尚、「前回LiveUpdate時刻」が普通の値であっても、「無間地獄」になることも何度もありましたので、普通の「前回LiveUpdate時刻」の表示によって正常shutdownが約束されるわけではありません。即ち、「前回LiveUpdate時刻異常」は「無限地獄」の十分条件ですが、必要条件ではありません。 面白いことに、問題発生マシンでLiveUpdateの失敗が発生したと思われる同じ時期に稼働中であった他のマシンでは「無限地獄」にならずに正常shutdownできますし、同じマシンが正常shutdownしたり「無間地獄」になったりしますので、ある時点でのダウンロードファイルが不正であるとか、NISエンジン関連ファイルが損傷しているとかというのではなく、ウィルスパターンファイル更新時や更新後のユーザーNIS-DBへの更新反映処理時における他の各種サービスの稼働状況で起きる競合(タイミング)事情によって、異常に陥るかどうかが分岐する確率過程のように、思われます。
MicrosoftのWindowsは見かけの立ち上がりを早く見せるために、システムの完全立ち上がり完了までに行われなければならない処理の大半をバックグラウンド実行して、ユーザー要求を受け付けるGUI画面を出来るだけ早く表示するという「インチキ」をやっています。 車でいえば、オートチョークでエンジンスタートさせて、エンジンが正常温度まで温まるのを待たずに走らせているようなものです。 Windows-Vistaはシャドウコピーを導入して安定性を高めた結果、XP比較でずっと重くなってしまいました。 NISを導入していないVista64では立ち上がってからディスクアクセスランプが１、２秒ごとに点滅するような安静定常状態になるまで、即ちエンジンが温まるまでの所要時間は、８コアの当方のマシンの場合で３０分程度ですが、NIS2013を導入すると２時間以上になります。 立ち上げ後、ログオンしてProcessHuckerで読み書きされるファイルと読み書き実行のサービス(モジュール)をモニターして見ると、立ち上げ時のSearchIndexerなどVistaの処理が一応終わった後でも、ディスクランプは点灯しっぱなしであり、クイックスキャンが行われる時間帯もありますが、大半は各ドライブの$MFTや$Logfileに読み書きしながら、c:\ProgramData\Norton傘下のNISのTMP、ログファイルに読み書きしています。 ウイルスパターンファイルのDBの整備にこんなに時間がかかるとは考えられませんので、多分、ユーザーのマシンに存在する全ファイルの各パターン毎のスキャン記録や危険度情報などが記録されたNISユーザーDBを各種ログファイルを読んで更新し、なお且つその整合性をチェックしているように思えてなりません。 NISの内部動作は公開されていないので想像するしかないのですが、NIS2002の時代には自動スキャンや自動LiveUpdateはありませんでした。 自動スキャン機能が出てきたのはNIS2009あたりからだと記憶しますが、全部のファイルをスキャンするには時間がかかるので、いろいろ工夫しながら仕組みを変えて現在に至っているようです。 NIS2009当時は、アイドル時に低priorityで逐次スキャンを進めていき、指定期日を過ぎても全数スキャンが完了していないと、アイドル状態は無視して全スキャンを通常プライオリティで強制実行する仕様だったと思われます。 NIS2011あたりになってくると各ファイルごとにスキャン済みの記録を行い、飛ばしスキャンを行うことで、次回の全スキャンサイクルの所要時間短縮の工夫があったようです（NIS2011、NIS2012では「初回のアイドル完全スキャンは必ず完了させてください」と説明されていました）。 NIS2012に比較して、NIS2013では格段にエンジンが温まるまでの所要時間が長くなったので、多分パターンごとについてのスキャン履歴を拡張導入した結果ではないのかと推定しています。 スキャン処理高速化のための工夫が、NISユーザーファイルDBの維持管理のためのbackgroundタスクのシステム占有率を上げてしまい、パフォーマンス低下を招いている状況だと推定していますが、NIS2013で確認されている重要な事実があります。 それは、手動スキャンとアイドル自動スキャンとは、スキャンの実行スケジュール履歴管理上はまったく無関係なのだということです。 ある時点でのProcessHuckerによるモニター結果では、手動完全スキャンが完了してから放置すると、アイドルタイム経過後に、なんと、アイドル自動クイックスキャンが走り出しました。 これから想像するに、手動スキャンの結果は各ファイル別のスキャン履歴、結果情報を集録したNISユーザーDBには一切反映されていないものと思われます。
NIS2013ではccsvchstも未だ32bit版であり、64bit化されていません。 64bit版OS上での32bitアプリやサービスはさまざまの不具合の種を含んであり、このため32bit版OSでは起きない不具合やパフォーマンス低下が64bitOS環境下ではおきえます。 また、64bit版の「７」「８」ではkernel32.dllのエントリーがVistaから拡張されており、VisualStudio2012で開発したアプリは内部でVista64用と7-64、8-64用に分岐処理しておかないと、7/8-64では動くが、Vista64ではAbortされるものがビルドされてしまい、ccsvchstのようなサービスプログラムの場合、今回のLiveupdate起因の不具合と同様に、表向きは不具合の発生がユーザーには認識されないので注意が必要だと思います。
一日も早く、完全64bit版のNISがリリースされることを待望します。