I've read most of the thread, but may have missed a few things.
First, I haven't seen what I consider is the real problem: The interrupt mechanism.
When a program is doing something it either has a process for being interrupted or not. The normal process consists of repetitive tests for certain kinds of signals that an interrupt is necessary: The ESC key being pressed, for example, or CTRL-F4; or the mouse clicking various keys.
This process of checking is called "interception." Some interception methods are written into basic computer language and others have to be written into the code.
Here's the problem, however it is done, each interception uses up a small increment of time. If one were to place an intercept test between every line of computer code, it would double or triple or even quadruple the length of time the program takes to do its work. This means that interceptions must be reasonably placed at key points.
Now I don't work for Symantec so I don't know their actual programming design, but logic dictates that it is something like this: Before and after each file is checked for signatures, the program checks to see if the computer is idle. While it is in the middle of checking a file, it waits for an interception until it has completed the task. This has a lot of good points. It ususally takes a matter of microseconds to check a file so the user won't even notice the hundredth of a second delay between pressing the cancel key or taking the computer out of idle and actually getting back control of the computer. Also it prevents the problem of the software re-examining a long file time after time because it was interrupted in the middle of its check.
But that brings up to the problem. What if Norton is in the middle of checking a really long file, one that takes over a minute (or five or ten minutes) to check, one of those large compressed installation or backup files? I am sure most of us have noticed, if we watch the full system check, how sometimes the program just seems to have locked up on some file or another; and how pressing cancel seems to have no affect ... until five or more minutes pass. Well, that probably means the app hasn't gotten to the point in its code where it runs another interception.
IF this is a fair description of what is happening, then it is easy to see why once Norton is immersed in checking certain files, we are going to experience what appears to be a lock up.
Are there things that can be done? Yes, both by the user and by Symantec.
I have seen other hard-working CPU intensive programs written that allow the user to determine the level of CPU usage. Mozy, for example, is an online backup program. Recognizing that if the user makes a lot of changes to the files on the computer, it would result in congestion during the backup time, it gives the user a number of options for minimizing that impact. The user can pick times for the backups or -- the method I prefer -- choose the level of CPU usage. This level setting is called "priority" and can be seen in the TaskManager if you right-click on any process. You can also set the VIEW of the TaskManager to include the Priority Column. If you do this you will see that not all processes are running at NORMAL priority. Some, like WinLogon, are always high; My Synaptics process is above normal; some are below normal.
The Symantec engine ccSvcHst.exe launched by the system (not the user) is always NORMAL. Now this would see to give it parity with all those other process with a Normal setting. Yes, but no. It has parity, but its demands are higher, so it simply bullies its way around all those other processes. You notice the impact at its worst when you find you can't use the other processes because Norton around has control of the system.
My workaround has been to reset the Priority of ccSvsHst.exe when I absolutely have to get my computer (actually, usually its my wife's computer that is needed instantly) back. I right-click, select priority and change it to Belownormal; and that does the trick within a number of seconds.
Now just recently I have noticed that TaskManager gives me a warning about doing this and then when I try to do this it won't let me. Fortunately, I use Norton's own Systemworks tool, Process Viewer, to accomplish the same task; and have no problem. Why TaskManager has suddenly begun resisting I don't know, nor do I know if this is an all-the-time behavior or a just-sometimes behavior. With the Process Viewer available, it just isn't an issue for me. The priority I assign stays with ccSvsHst.exe until I change it back or until I reboot the computer.
What I would like to see is Norton designing a better priority assignment into the process. If this is a continuing issue, then there must be a way they could do that. Once option is to index those files that take a lot of time to scan and when the scanner encounters those files to change the priority of the app to Belownormal; and when it finishes those files, to then shift the priority back to Normal. Even organizing the order of scanning so that it scans the biggest files first (taking advantage of idle time immediately it appears) and getting them out of the way under the Belownormal setting might be a real fix to the problem.
Anyway, for now, for user with this problem, the workaround seems to still be there. What would be useful I think, both for us users and for Symantec, would be for more users to try this workaround and to report back on its effectiveness.