Home for HMNL Enterprise Computing

Enterprise Computing

    High CPU Usage by NIS.EXE after closing Google Chrome

    Ian Tree  03 June 2015 10:02:22

    High CPU Usage by NIS.EXE after closing Google Chrome


    This issue has been posted in various forums around the internet, there does not appear to have been any definitive diagnosis or fix discovered for the problem.

    The Problem


    Starting about a month ago every time that Google Chrome was closed then a noticeable increase in CPU consumption was observed, this higher than normal CPU consumption would continue until either Google Chrome was restarted or the system was rebooted. The task manager would show that a single thread in NIS.EXE was consuming high levels of CPU. The problem was observed on a laptop running Windows 7 Professional, Google Chrome and Norton Internet Security, all software was at the latest maintenance levels.

    Investigation


    Starting ProcMon while Google Chrome was running and then closing Chrome, waiting until the high CPU was observed and then stopping the collection in ProcMon. Examining the activity for the NIS.EXE process revealed the following behaviour. While Chrome was running NIS would attempt to check a file called c:\Users\UserName\AppData\Local\Google\Chrome\User Data\Default\Secure Preferences (where UserName is the current Windows user), NIS would find that there was an exclusive lock held on the file and would gracefully give up and try later. Once Google Chrome was shut down the file lock on the offending file was released and NIS would again attempt to check the file, this time it would get an "Access Denied" response from the CreateFile() attempt on the file NIS would then remain in a tight loop retrying and failing on the sequence of CreateFile() calls. NOTE: I could see no obvious reason why the CreateFile() cal should have failed.

    Fix


    Excluding the offending file from both Scan and SONAR in the NIS settings appears to have resolved the problem.

    Speculation


    Google Chrome modifies the file during startup and this triggers a file update notification that is picked up by NIS. NIS attempts to examine the file and hits the exclusive lock held by Chrome and so gives up, making a note to try later. On shutdown of Chrome the file is again modified and a new notification is again raised and picked up by NIS. There is some condition in the security attributes of the file that cause the NIS attempts at access to fail, the particular access failure is not expected by NIS and it continuously retries the operation on the file, this tight retry loop consumes the high level of CPU.

    Update


    After about 24 hours the behaviour returned, examination with ProcMon showed the same pattern of activity on the executable file: c:\Users\UserName\AppData\Local\Google\Chrome\Application\Chrome.exe so this file was also excluded from the Scan and SONAR in the NIS settings.



    Share: