This post is in effect a follow-up to an older thread "NIS 18.5.0.125 causing BSOD on Multiboot System", as I've experienced a similar issue and wanted to share my experiences to help others out there, and in case Norton are still interested in actually fixing this bug.
I have multiple Windows XP SP3 installations multi-booting on the same PC. To start with only one of them (E:) had NIS, and I wanted to install NIS on another (C:) - this is what happened:
Starting point - NIS 2010 (17.8.05) installed on E:
Installed NIS 2011 (18.6.0.29) successfully on C: . Tried to reboot into E: , got a Blue Screen of Death (BSOD) - generic Stop Error (didn't record the code, sorry), no mention of any particular driver file (unlike others in the thread who got a direct mention of symefa.sys in their BSOD).
Came to Norton forums to try to figure out how to fix it - best looking answer to me was this official post - unfortunately I couldn't actually get my broken E: NIS2010 instance to boot into Safe Mode either :-( So next I tried the rename E:\WINDOWS\system32\drivers\NIS\...\symefa.sys hack that had been suggested, and this seemed to work without needing to go into Safe Mode. Phew! I was able to boot back into E: , albeit missing a driver. (There was no need to interfere with the NIS 2011 on C:, and for the record, I booted into a third, non-NIS, XP instance to do the renaming of the sys file on E:)
I was hoping to continue using NIS2010 on E: temporarily without having to upgrade it immediately, and hoped there would be a solution that didn't involve hacking away one of its drivers, so I continued scouring the forums and came across this post, a much earlier one about a general symefa.sys BSOD (not related to multiboot):
It suggests deleting the \System Volume Information\efadata directory to remove the corrupted database in there.
So I went back into my third non-NIS boot option and restored the symefa.sys file, and deleted the efadata folder on E: instead - and voila, E: managed to boot fine! Of course it wasn't as simple as that, after booting into C: again, it nearly every time E: went back to BSOD again, until I went into the third boot option in order to delete efadata from E: . I managed to repeat this several times, and checking from the timestamps on the files in efadata, it was definitely the case that NIS 2011 on C: was writing to the efadata directory, and presumably writing a database into there which NIS 2010 couldn't cope with :-( (Each time after booting NIS 2011 C: , the only way to guarantee NIS 2010 E: would boot again was to delete E:'s efadata).
What's intriguing (to me anyway) is that the E: volume ISN'T EVEN MOUNTED on the C: XP instance! NIS 2011 (driver?) is "secretly" accessing the \System Volume Information\efadata directory of a volume that XP hasn't even mounted. (that's part of the reason why I went to a third XP instance to delete the corrupted efadata dir on E: - although I could have mounted E:)
Anyhow, (sorry this is so long!), I realised this wasn't sustainable and would have to upgrade to NIS 2011 on E: - so for my final piece of experience that might be of use to others - I UPGRADED from NIS 2010 to NIS 2011 - and it all works fine now! The important piece of info here is that I did NOT have to uninstall NIS2010 first - which I was loathe to do because a) it would leave E: unprotected for longer, and b) I couldn't be bothered to work out the exact procedure to transfer my licence key across from the uninstall to the new install ( I figured "upgrade" would do it automatically for me, and it did).
Hope this helps somebody out there - and hope that the Norton/Symantec developers can fix this - it really isn't acceptable for an incompatiblity to cause a scary BSOD which renders the entire OS unusable - worse still, I couldn't even get in via Safe Mode. How is a non-technical user supposed to cope with this??