The Norton Conundrum
Sacrilegious as some might find the statement to be, I have switched over to Norton Internet Security 2008 again 🙂 Yes, I went through all of the other security suites around (in fact, I went through some several times over) before I came back to Norton after trying it the first time. On my machine running Vista with 2GB of RAM, NIS 2008 works beautifully. Of course, I must mention that NIS 2008 was really sluggish and slowed down the system a lot on my wife’s XP SP2 machine with 512MB of RAM. But since I’m really interested only in protecting my own machine, NIS 2008 fits the bill beautifully :p
But all that’s beside the fact. I switched over to NIS 2008 for the second time yesterday and since my machine was performing well, I decided to tax it a bit more by installing the Norton Add-on Pack which adds anti-spam capability to the NIS suite. And that’s where the trouble started 🙂 The Add-on Pack installed fine but I couldn’t access any of the configuration screens because each screen would throw up several Internet Explorer Script errors about not being able to "instantiate object".
I contacted Symantec Tech Support since I was a registered user. The first tech I got was the usual "uninstall and re-install again" variety which didn’t seem to even know about the issue. I simply told him that I had already tried the uninstall-re-install routine and that it had gotten me nowhere and that this sounded like an ActiveX issue and asked him if he knew which DLLs needed to be registered in order for the ActiveX objects to be correctly created. He immediately said that he was transferring me to his supervisor 🙂
The supervisor (or colleague, I wasn’t sure which) turned out to be not so prone to work from a set script. He listened to what I had to say and suggested a few things that I had tried before. When I asked him about what DLL to register, he suggested MsouPlug.dll which can be found in \Program Files\Common Files\Symantec Shared\AntiSpam and I tried that and got an error saying that the DLL registration failed with an error code of 0x80070005. Now I’d gotten this far on my own the last time I ran into this issue – which was when I had had NIS 2008 installed the first time a few weeks back. So I told the tech guy the issue and he suggested a few other things.
While I was trying his stuff, I was also doing some Google searches on my own and my latest combination of search terms turned up a site that I had not found before. Now all this time, my biggest question had been whether the DLL registration error was normal or if there was something really wrong. I finally had a resource which suggested a way to check on this. The site in question mentions RegMon but I actually used ProcMon instead but you should be able to use either one depending on the OS supported by each utility.
Basically, you try to register the DLL in question by using the regsvr32.exe command and watch the regsvr32.exe process via one of the above apps to see if there are any ACCESS DENIED results on a registry key open request. I did that and found a registry key which had the problem. So I fired up trusty old regedit.exe and changed the permissions on the key in question to give the Administrators group on my machine full access to the key. I then tried the DLL registration again, it failed again. I checked and noticed that the keys I had fixed earlier now had sub-keys and they were inaccessible. So I changed the permissions on those and the DLL registration worked.
At this point, I told the Symantec tech that I should be able to resolve the issue on my own and terminated the chat. But it wasn’t to be that simple. Registering the MsouPlug.dll didn’t seem to do anything with regards to the issue I had with accessing the Anti-Spam configuration options. So I took a look at the error message again. It was pointing to the error message as originating from the Options folder inside Symantec Shared from a file called whitelist.htm inside optRsHtm.loc – I checked the Options folder and there was an optRsHtm.loc file but no whitelist.htm file. It looked as if the whitelist.htm file was inside the optRsHtm.loc file and I needed a way to get at it.
g_pSymDisp = new ActiveXObject("Symantec.Options.SymDispatchWrap");
So, I went rooting in the registry for the HKCR\Symantec.Options.SymDispatchWrap key and what do you know? That key was inaccessible as well! So I fixed the permissions for the key and it still wouldn’t work. I checked to see what that key referenced and found a DLL named UIHelper.dll that wouldn’t register. So it was back to ProcMon to trace which registry keys were at fault and then change the permissions on those and so on. After some further back and forth and changing permissions on a few other registry keys and registering a few other DLL files, I was finally able to access the configuration screens for Anti-Spam with no issues whatsoever 🙂
I wrote this entry so that anybody running into similar issues can find the solution since the Symantec knowledgebase does not appear to have any reference to this issue. But if you are unable to figure out the problem on your own, drop me a line and I’ll see what I can do to help 🙂