Norton Internet Security / Norton AntiVirus

[jimmiller]

NIS 19.6.2.10 (and possibly earlier versions) causes the System process to accumulate file handles and never release them.  I have verified this with Process Monitor.

The cause is IRP_MJ_CREATE operations on C:\ProgramData\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\NIS_19.1.1.3\IRON\IRON.DB-journal (on my system), with the result NAME NOT FOUND. 

Over time, this elevates the handles used by my System process to many tens of thousands.  I believe this happens when the periodic system scans run, though I'm not completely sure about that.  The handle leakage doesn't happen continuously, but rather in bursts on some days.

Windows 7 64 bit

[PieterV]

Hi, the not found event is not unusual, but it should not result in leaked handles.

Can you please provide some more details of how you track the system handle count, and how you associate the not found event with leaking handles, as well as details of OS and product versions?

Pieter

[jimmiller]

Sorry for the late reply.

I'm on 19.7.0.9 now and the same thing continues to happen.

Rather than giving a detailed explanation of my procedure right now, which involves cross-referencing Process Monitor entries with Process Explorer data, etc., I'll just note that I can stop the slow but inexorable upward climb of open handles in my System process by disabling Smart Firewall and disabling Antivirus Auto-Protect, then immediately reenabling both.  This works every single time, that is until System starts leaking handles again, maybe several days or a week later, at which time I repeat the same process.

Thanks,

Jim Miller

Windows 7 64

[huwyngr Norton Fighter]

You might try for the recent update to 19.7.1.5 if that has not come down automatically since you posted.

FWIW I followed exactly the instructions posted here to getthe update and I restarted the PC before running LUD. I found that the version number had changed to the new one before I even ran LUD but I ran it anyway.

[AdamG]

Is it possible to get more information? I'm specifically interested in getting the number of open handles according to Process Explorer (run Process Explorer as Admin, double click on the System process, select the Performance tab, return the number of Handles). I’d also be interested in a list of open handles. In Process Explorer, select the system process, View menu->Lower Pane View->Handles, File menu->Save As, send me the saved file.

Thanks!

[jimmiller]

Here's the current data from my system.  This is after 3 weeks of uptime, and with an active System handle leak NOT currently in progress (although during this uptime there have been about 3 previous leak episodes which I eventually quashed with the procedure mentioned above, which is why my handle count is so high now):

Handles:  55003

Peak Handles:  58378

GDI and User Handles both 0

Total handles open across the whole OS about 115730.

File you want attached.

[AdamG]

Thanks for the information, Jim. This confirms an unusually high number of open handles in the SYSTEM process (which is shared by NIS and other processes on the machine), specifically for HarddiskVolume3, HarddiskVolume5, Tcp and Tcp6 devices. We've attempted to reproduce this in-house and to find what could cause this via a code review and so far have not been able to determine a root cause.

NIS is capable of writing out detailed logs of what it's doing on the system. Would it be possible to send logs using the following steps?

1) Turn on logging. Instructions are available here (http://community.norton.com/t5/Forum-Feedback/Logs-User-Mode-Dumps-and-Complete-Memory-Dumps/m-p/708...). We only need the SymNRA logs, not LUE, Wireshark or other log types mentioned in the link. Within SymNRA's Advanced Options dialog, we only need "Turn on Debug Logging" and "Do not upload". We do not need "Turn on Performance Monitoring" as suggested in the link.

This will unfortunately require a reboot of the system, which I suspect will temporarily resolve the issue if it was currently occurring.

2) Reproduce the issue and note the time the issue is occurring.

3) Press "Finish" on the SymNRA window, collect the logs as described in the link, and send the logs and time the problem was occurring to me.

Thanks again for helping us isolate what's happening.

-- Adam

[jimmiller]

Ok.  It might take a week or two for me to notice the problem.  I'll report back.

[jimmiller]

I installed SymNRA and rebooted, but I don't want to use it, because, unbelievably, the program can't be minimized to the taskbar or the tray, and its GUI can't even be moved on the screen!  It takes up a fixed chunk of space in the upper right corner of my screen, blocking access to the upper-right controls of windows, which I always run maximized, and it partly blocks a program window's client area in some cases.

In order to log the error I've been having, I would have to let SymNRA run for several days or a week, and that's just not practical with the GUI that SymRNA has.

Any alternatives?  All I need is a SymNRA that can be minimized.

[AdamG]

Logs can also be gathered by the following method

1. Wait for the problem to occur

2. Create a local folder, e.g. c:\log,copy the attached file there, and rename NIS.ctl.txt to NIS.ctl.

3. Bring up an administrator command prompt

  a. go to the Start menu->Accessories

  b. right click on Command Prompt

  c. select "Run as Administrator"

3. In the administrator command prompt run the command

    logman.exe start NIS –pf c:\log\NIS.ctl –o c:\log\log.etl -ets

4. Make sure the problem is happening by observing open handles in the SYSTEM process

5. To stop logging, in the administrator command prompt run the command

    logman.exe stop NIS -ets 

6. Send the file c:\log\log.etl to me.

Thanks,

Adam