12-20-2011 01:27 AM
The background to this posting can be found here: http://community.norton.com/t5/Norton-Internet-Sec
However, as the above thread evolved into an off-topic discussion on memory/performance issues with Crypt32.dll, I restate my own findings here. Briefly, to rectify a Crypt32.dll memory leak on my XP/Sp3 box, I uninstalled KB2641690 and then reinstalled the same hotfix with the /B:SP3QFE switch. The 'run' command used was: WindowsXP-KB2641690-x86-ENU.exe /B:SP3QFE
After reinstallation, Crypt32.dll properties confirmed that the QFE branch had been installed. Version: 5.131.2600.6154 (xpsp_sp3_qfe.110927-1620). Total Commit Charge (shortly after boot) was around 290mb, as it should be, rather than 430mb. If this holds, and that's a big IF, maybe the solution to my (XP/Sp3) memory problems.
More on Crypt32.dll and the 2 branches of development for updates, GDR (General Distribution Releases) and QFE (Quick Fix Engineering), here: http://social.technet.microsoft.com/Forums/en-US/i
01-03-2012 12:59 AM
Postscript: as it turned out, the Crypt32.dll 'fix' (as described in this thread) didn't work in my case and the high memory issue (primarely related to one instance of svchost.exe, explorer.exe, ccsvchst.exe and a few other processes) returned.
As before, on my 'troubled' computer, on-off, I lost about 130mb of 'commit charge' memory for no apparent reason.
Looking further, based on leads from the Web, I found some oddities with my prefetch folder and (against standard advise to leave prefetch alone) decided to clean it out and 'start' this folder from scratch. So far, it seems that this procedure worked and my boot commit charge is back where it should be. Keeping my fingers crossed...
Generally speaking, the prefetch folder is self-regulating and should not be messed with, but, as I found one trace file almost a year old (MSMSGS.EXE-2B6052DE.pf), the automatic clean-out of the prefetch folder didn't work okay. So, I simply deleted all the files, including layout.ini, in the prefetch folder. New prefetch (.pf) trace files started to reappear quickly, but, layout.ini did not. To force the creation of layout.ini, I went to Start/Run and typed: Rundll32.exe advapi32.dll,ProcessIdleTasks
After some time (with the harddisk spinning), layout.ini reappeared. Then, I rebooted a couple of times to be sure that prefetch worked okay ... and that layout.ini had a chance to rebuild itself properly. This is a short version of what I did. FWIW.
01-03-2012 07:14 AM
Thank you for that information.
I forwarded it (via PM) to a Symantec Engineer for his review.
Actually, I had this same problem, but it vanished about 3 weeks ago.
01-03-2012 07:59 AM
If your problem was related to prefetch, it's possible that it vanished after one or more 'bad' prefetch trace files had been flushed and/or the layout.ini file had been rebuilt. This is beyond my expertise .. and only an assumption.
But, to check my findings I temporarily removed some trace files in the prefetch folder on another computer not having the high (on-off) memory problem. Thereafter this computer all of a sudden showed the same high memory symptoms. After restoring the files, the commit charge (VM Size) went down to normal and what it was before I messed with prefetch. Maybe a clue...!? Best, CBA
01-03-2012 08:43 AM - edited 01-03-2012 08:44 AM
Try this quick fix next time. It also has the option to force the layout.ini to rebuilt.
01-03-2012 09:54 AM
Thanks, been there done that. I looked at TweakPrefetch, but, didn't like or use it .. as I prefer the transparency of knowing what I do with the registry. The prefetch settings in question can be changed manually and I didn't find any option to force a layout.ini rebuild.
I do believe prefetch is better left alone unless you have a problem .. so no need for a fix-program of this kind. Of course, imho. Best, CBA