I had to do the correction Solution posted above (deleting SymantecKeyChain and re-activating NAV) again today, and I think I may have a handle on what's going on here.
I believe it is possible to trigger this failure by doing a Safe Boot followed by doing a Disk Utility > Repair Permissions.
By the way, the failure appears to happen NOT on the first boot after doing those, but on the SECOND boot (and thereafter).
This would suggest that there is something in those procedures which is undoing something that NAV depends upon. My guess would be that NAV install/activation is setting special permissions which get deleted when doing the above. This would require that NAV depends upon such special permissions *AND* fails to recover cleanly if it discovers those special permissions have been reset.
It would also require that deleting the keychain and re-activating (i.e., the posted Solution) *DOES* re-establish those special permissions.
-------------------------------------------------
Now, there may be other ways for the presumed special permissions to get discarded other than hitting the system with the hammer of Safe Boot and Repair Permissions. Since I don't know what NAV is relying on, I can't guess what more common events might undo it. But the fix in any case would EITHER be to change NAV not to rely on such special stuff *OR* to have it recover robustly if it discovers that special stuff has gone away -- regardless of how that might have happened. I.e., restoring the needed special permissions on the fly rather than simply reporting that it can't start the Scan Engine.
Perhaps it already IS trying to recover, which explains why it doesn't fail on the first boot after doing the above, but is screwing up the recovery in some way so that subsequent boots produce the failure.
It may be relevant that my normal log-in account on the Mac (10.7.4) does not have Administrator privileges.
--Bob
