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.
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.
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.
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 PCbefore running LUD. I found that the version number had changed to the new one before I even ran LUD but I ran it anyway.
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.
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.
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/70899). 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.
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.
I believe I'm hitting the exact same problem as the OP with Norton 360 6.2.1.5 on Win 7 32-bit.
It happened after I was recently upgraded to this version. I was running a previous version of Norton (360?) which had different looking UI and didn't have this problem. I unfortunately don't have the details but if there's some way to find out (e.g. installer log I can look at), I can try to provide that.
I'm seeing the System process handle count climb into the many of thousands. Before finding this post, I stumbled across the workaround to stop the leaks of disabling then re-enabling auto-protected. When leaking, it was leaking at the rate of maybe 1 or 2 handles per second.
I will try to get the logs as directed earlier, when I repro it.
I don't have the cause pinned down like the OP but when running Process Explorer as administrator, under the System process I can see a TON of handles to \Device\HarddiskVolume2.
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
Hi, unfortunately, I'm hitting the System handle leaks right now on Norton 360 6.2.1.5. I see System consuming 24,864 handles as I'm writing this message.
Also, your above instructions don't work for me. When I try running those, I get:
"E:\todelete>logman.exe start NIS -pf e:\todelete\NIS.ctl -o e:\todelete\log.etl -ets Argument '-pf' is unknown. Argument 'e:\todelete\NIS.ctl' is unknown. Argument '-o' is unknown. Argument 'e:\todelete\log.etl' is unknown.
Error: The parameter is incorrect."
(I saved the NIS.ctl.txt file to the e:\todelete directory and renamed it to NIS.ctl.) Are there equivalent instructions for Norton 360? System is now at 24,948 handles.
I'm not sure why you can't get to that page, but the manual logging instructions are more useful for you anyway.
It looks like the '-' key got replaced by the forum software with a different character, perhaps an EM-dash. Please type the command by hand, or cut and paste but then backspace over each dash and replace it with a minus key.
You're right. Hand typing it out using a minus works. Unfortuantely, I shutdown my machine for a few hours after the post and the problem isn't reproing right now. Will take logs when it happens again.
I was able to get a log when I saw System leaking handles at about 1 per second. I hope this was a legimtimate repro case. How can send it to you? I'm a little reluctant to post it here publicly as I don't know what's contained inside and whether there's any sensitive info inside that shouldn't be posted publicly
Feel free to send me a private message w/an email, if that's the way.
Any progress on this, esp. w/Norton 360 6.2.1.5? I'm still seeking the massive System handle leaks from time to time. The workaround of disabling then re-enabling auto-protect works but I don't usually notice the leaks until it's leaked several thousand handles.
Were my logs helpful or do you need more repro cases?
Thanks for checking in and sorry for not replying sooner. I was trying to get an exact date for a fix.
The logs helped immensely in tracking down the problem, and the fix should be out next week. Unfortunately I don't have an exact date at this time.
In the meantime, this should also be resolved by clearing out your downloads folder either by deleting the files there or by moving the files elsewhere.
Sorry for the inconvenience and thank you very much for helping to track down this issue.
Adam - downloads folder? Do you mean a Windows downloads folder, or a Norton-specific folder?
Thanks, cwerdna, for getting your report in.
I've been preoccupied with a different, longstanding Norton bug which is causing me to revert to NIS 2011, and thus this handles problem fell off my priorities list.
> Adam - downloads folder? Do you mean a Windows downloads folder, or a Norton-specific folder?
Sorry, I should have been more specific. The workaround is to move or delete files from your web browser's downloads folder. The problem manifests when the web browser re-opens downloaded items, for example when viewing downloaded files. Again, the real fix will hopefully be in your hands next week; this workaround is to help ease the pain until then.