Norton Internet Security / Norton AntiVirus

[huwyngr Norton Fighter]

---

Jeff09 wrote:

Hi huwyngr,

Thanks for your reply.

I cannot find the file "PD7_ContextMenu.exe" on the Avanquest site.

I did find, download, and execute the file "contextmenu.exe". The program executed properly; however, I still have the same issues.

Jeff

---

Sorry I should have corrected that first filename since the PD7_ was my addition to identify it in my Internet Downloads folder.

When you say that the program executed properly do you mean you have looked in the PowerDesk folder and found the two files there, dll and old with the different sizes and dates?

If not then I'd try the manual route.

If you do see that the new file has been delivered there then I can only imagine that you have another program installed that also has the problem, as other users here have discovered by following the elimination route using ShellExView  - the Shell Extensions Manager from Nirsoft which is a very reputable source.

Have you seen the message(s) here describing how a user has gone through this and identified the trigger program?

Shout if you need more help on this!

[huwyngr Norton Fighter]

Oh I'm not doubting what you see and report.

Please see my other reply on the only suggestion I can make.

[Jeff09]

Hi huwyngr,

I am using the program ShellExView. That is how I identified "IE Context Menu Class". I started with the four Symantec files because they are newer (by over 1-1/2 months) than any other files. I started by disabling all four, and then worked my way down until "IE Context Menu Class" was idenfied as the only one that is causing problems. And, since the modification date on that file makes sense with respect to the timeframe of my problems, I thought it was the culprit.

Are you suggesting that an older program/application is causing the problem even though everything was fine until the file referenced above was installed/modified?

Like I said earlier, I am not trying to point fingers at anyone. I am just trying to correct the problem.

(I will check the PowerDesk folder to confirm that everything was installed correctly. I'm reasonably certain that it did; but, I will confirm.)

Thanks

Jeff

[martike]

It’s my understanding that because certain other applications (not Windows Explorer, not PowerDesk, not Norton) do not conform to standards, they represent potential problems. They work perfectly themselves, and continue to be harmless until a trigger comes along and exposes their faults. The recent update to NIS2009 was such a trigger.

 

From a techie’s point of view, the problem is, therefore, not Norton’s fault.

 

But from a normal user’s point of view the problem wasn’t there before the NIS2009 update, and now it is, so it must be Norton’s fault.

 

What you need to do is re-enable the Norton entries in ShellExView (how did you disable them in the first place? They’re protected.), then disable all the others (no matter how old they are, my problem was caused by an eight year old application) one-by-one and check your Windows Explorer each time until you find the application which has been triggered by Norton.

 

So far in this thread Better File Rename and ZipMagic have been discovered. What’s yours ?

[huwyngr Norton Fighter]

<< Are you suggesting that an older program/application is causing the problem even though everything was fine until the file referenced above was installed/modified? >>

Absolutely! 

I'm reporting what I experienced last year when this first cropped up with the V1 > V2 of N360 since I was the one who brought it up here with Norton who then tracked it down to the situation with PowerDesk. Do a search in the N360 Forum on [PowerDesk crash V2] and I'm sure you will see exactly that complete with Microsoft's blaming Norton when it was PowerDesk and the change that Microsoft made that triggered the event.

Add to that the current experience of at least one user totally dogmatic that it had to be Norton for the reasons you give and coming back after analysis having found the specific program that caused it. 

I think martike has the best experience and suggestions since so far Norton have no evidence that they can change anything in their programs.

[Jeff09]

martike,

There are 363 entries shown in ShellExView.

Prior to the recent NIS update everything worked well.

Now there is a problem. Should I thank Symantec for creating a problem, with no diagnostics to help identify the cause of the problem?

ShellExView allowed the "IE Context Menu Class" entry to be disabled. That's how it was disabled.

I'll respond back when I have the time to go through and identify which of the 363 entries (other than "IE Context Menu Class") is preventing right-clicking from working. That may not be for a while, though.... in which case, I will be disabling "IE Context Menu Class".

With all due respect, if you can't understand why the end users get upset at a program like Norton Internet Security when a situation like this arises, I don't believe you are looking at the situation objectively. As the licensee of a program, and I have moved through the installation phase and the program (and everything with which it interacts) work flawlessly together, then I have every right as the licensee to state that the reason that my system stopped working is because of the change/update that was made to the program. This is clearly the case with Norton Internet Security and the latest update.

Jeff

[huwyngr Norton Fighter]

Jeff -- of course we understand. It's the most understandable thing in the world to feel the way you do, especially when one has been through the experience as I have and as have the others here who like you started dogmatically certain that it was the fault of Norton.

I have been active in these forums for nearly a year now and you are welcome to check my posts to see about understanding and objectivity although there are rather a lot of them.

Please do me a favor: read the first message in this long thread and then click on the green solution link in it and see what he has to say. Then go back a few messages to this one and to this one and see what he discovered by doing the troubleshooting with Shellexview that has been suggested.

And then click on this link which will take you to WIKI to explain the logical fallacy referred to as "Post hoc, Propter hoc"

or 

"Since that event followed this one, that event must have been caused by this one." 

Forgive me if you find me tedious but I've been through this on my own machine and I've seen it with others -- imprimis is not the only one here with this experience; just the other day someone identified another program on their computer -- a zip utility -- that was causing the problem.

[martike]

Jeff09,

 

Yes, it does appear that the error is not caused by Norton NIS2009, but simply that NIS2009 has recently had an update applied that has triggered a latent hidden error elsewhere. Under these circumstances it’s for you to decide who is to blame, I’m not making that judgement, but I can see that the situation is a lot more complex than it first appeared.

 

Of the 363 entries in ShellExView, how many are Microsoft ones ? If you sort on Company you’ll be able to separate them out and you can ignore them. Then you look more closely at the non-Microsoft ones which remain (in my case there were 28 remaining), and you can see them in company groups.

 

Disable them in groups. After each disable, check if the Windows Explorer crash still occurs. If yes, then re-enable that group and move on to the next. If no, then you’ve found the problem. It’s one of the entries in that group. Which one doesn’t really matter although you could identify it by breaking down the group and checking individual entries.

 

I expected this to be a long and tedious task but in fact it only took about ten minutes before I hit on ZipMagic. Disabling this solved the problem and so I uninstalled that application. I’m more willing to lose that than to lose functionality in NIS2009.

 

But while you’re doing this the Norton entries have to remain enabled, otherwise the conditions for the error to occur no longer exist.

 

I still don’t understand how you managed to disable the Norton entries anyway. In my ShellExView display they were shaded in red and simply would not disable. It is possible to overcome this and disable them anyway but you need to turn off the protection on NIS2009, and I hesitated to do this, but you haven’t mentioned going through this procedure. Anyway, that isn’t central to solving this problem so let’s not get side-tracked by it.

 

Good luck.

[huwyngr Norton Fighter]

Martike,

<<  Disable them in groups. After each disable, check if the Windows Explorer crash still occurs. >>

Although I have Shellex installed I've not done troubleshooting with it.

Should one reboot after each group disable or is that not necessary?

[martike]

I didn't reboot. The disable/enable appears to be immediate. My 28 potential culprits fell into 7 or 8 company groupings and I hit the one I was looking for on about the 4th attempt. It really did only take 10 minutes. Once I'd identified the application, I didn't bother finding precisely which entry was the cause.

In the previous example, which started this discussion, it was possible to simply update Better File Rename to a new version to solve the conflict, but in my case ZipMagic seems to have disappeared years ago (I think its current incarnation is Stuffit) so there was no possibility of an update. I simply dumped it.