Blog: Symantec

We received Event ID:333 "An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system's image of the Registry." On Windows 2003 R2 terminal server running SEP 12.1.

We could reproduced the issue by simply running a SEP scan. We notice all user registry hives from everyone that has logged in are loaded into the registry's HKEY User directory for scanning. Depending on how many users have logged into the server, this can quickly add up. When this happens, it causes the registry memory to become so low that it fails to write any new data to the registry until the server is restarted. [more]

The first event logged would generally state that the system's available memory for the registry was low. After that, Event ID: 333 would be logged about every 30 seconds.

We found this article that helped resolve this issue In the article are some memory pool settings in the registry with a link to:;EN-US;312362.

In the article, it states for PagedPoolMax, "Setting the value at 60 informs the Memory Manager to start the trimming process at 60 percent of PagedPoolMax rather than the default setting of 80 percent. If a threshold of 60 percent is not enough to handle spikes in activity, reduce this setting to 50 percent or 40 percent."

During our testing, the value of 60 still exhibited the low resource issue. Setting the PagedPoolMax value to 40 (decimal) along with the other TCP chimney settings stopped the registry errors from Symantec scans.


I was assigned recently to a task that had been started by another network engineer. The initial problem started when software updates were applied to the server. The network adapter lost its driver and wasn’t able to talk to the network, let alone the world. He was able to restore network connectivity by reinstalling that driver and resolving other network issues that had arisen, but was unable to fix an issue where network drives were not mapping to the server in the time he had available to him.

When I took a look at it the next morning, all signs led to the network card going bad and needing to be replaced. However, as I was continuing to troubleshoot, I noticed that they had the Network Threat Protection module for Symantec Endpoint Protection (v. 11.0.4) installed. I created a rule on the firewall to open all traffic between sources on the network and immediately people were able to map network drives and start working.


Recently, I needed to log into the console of our PGP Universal Server to verify the version level of Apache installed. Unfortunately, the Universal Server is (intentionally) locked down since all the tools required to manage the server are built into the web console. When the server is initially installed, you do not have access to log in via SSH or through the console because of the locked nature of the kernel. (Sidenote: there are supported ways to set up SSH access through the use of private keys). Fortunately, since the server is based in Linux, it’s trivial to “break in” and get access to the console. All that is required is physical access and some downtime. [more]

Step 1: Reboot the server

Step 2: When Grub loads, interrupt the auto-boot sequence and press ‘a’ to edit the kernel arguments before booting

Step 3: Add a space and the word “single” (lower case) to the line and press enter.

Step 4: Enjoy your root access.


We recently ran into a problem where a job in Backup Exec was failing when backing up the vmdk using Virtual Consolidated Backup (VCB).  Backup Exec was reporting the following error message: and reportint the following error message:  "The Virtual Machine resource is not responding."  After some trouble shooting and research we discovered an unallocated disk may cause Backup Exec to fail with that error when another allocated disk is beng backed up.  This turned out to be the problem in our case as we had an unallocated disk. [more]

Here is some more informatino about the issue from Symantec:


Recently, I was pushing out an upgrade to Symantec Endpoint Protection (SEP) when I came across an issue with a machine that caused the upgrade to fail, though I don’t believe it was caused by the upgrade itself. Basically, the older version of SEP didn’t quite uninstall completely and the new version of SEP didn’t quite install completely. There was just enough stuff broken in SEP so that it was effectively useless. Virus definitions were not downloading and active scan was simply not functioning. The easiest way to resolve this problem, naturally, is to uninstall both versions and reinstall.

Unfortunately, the uninstall failed with a “fatal error”. At this point, I could’ve gone to CleanWipe and had it remove SEP completely for me, but I’ve had instances where CleanWipe doesn’t get rid of all the registry keys and a new install will fail. Below are two links for the manual uninstall document for SEP. [more] – How to manually uninstall Symantec Endpoint Protection client from Windows 2000, XP and 2003, 32-bit Editions – How to manually uninstall Symantec Endpoint Protection client from Windows Vista, Windows 7, and Windows 2008 32-bit

It’s a long document, but it will effectively let you remove all traces of SEP from your PC.


When installing or making changes to the Symantec Endpoint Protection client, be aware that the SEP firewall policy can cause Windows Firewall to 'reset' or change its configuration.  I've seen several versions of Windows OS change to an active firewall config with no exceptions under the following 2 conditions: [more]

  • SEP client with an enabled, default firewall policy is installed for the first time
  • Existing SEP client has its applied firewall policy withdrawn

This has been seen with several 11.0.6x builds of SEP, although it may be applicable to other builds as well.  This occurs even though the SEP firewall module (Network Threat Protection) is not installed.  When a Windows desktop has its firewall enabled with no exceptions and there is no group-policy in place to re-apply a previous config, it may become unreachable remotely via any protocol, while at the same time the user may notice no change and continue working normally.  If the Windows client happens to be a server, all connectivity to that server may be lost, except via console.

I suggest rolling out new SEP clients after the firewall policy in that group has already been withdrawn.  For existing clients where the firewall policy needs to be withdrawn or disabled (ie overriding Win7 firewall config), test a small subset of clients in a separate group before making the change to normal production groups.


When creating scheduled reports in the SEP Mgmt console, be sure to check your filter settings after creating (see image below).  The default filter is just for the past 24 hour period and also includes all clients SEPM can see.  If you want to set a different coverage interval, such as weekly or monthly, or apply the report just to specific clients or sub-groups, you need to create and save a custom filter. [more]


When I logged onto a customer’s terminal server/dc, the c: was completely out of space.  I loaded Space Monger and saw that most of the files taking up room were in c:\program files\sav in .xdb files.  I ran disk cleanup and compressed old files which freed up about 5 GB.

I then started researching what was downloading the xdb files.  I saw that they were dating back to almost 60 days ago and every day since.  Each file was approximately 100 MB. 

I looked at all of the Symantec products on their system and talked with the person who had updated Symantec Antivirus (SAV) to Symantec Endpoint Protection (SEP).  He asked me to check the scheduled tasks, and I discovered that there was a scheduled task that ran to download definitions to the old SAV program before they were upgraded to SEP.  I disabled the scheduled task and deleted the xdb files to finish cleaning up an additional 4 GB space.


I was attempting to install SEP on a server that was local to me, but remote to the SEP manager. The problem here is that the SEP manager generates a 90 MB package before pushing it out to the machine and starting the install. This would’ve taken a good bit of time to copy over the VPN to the server here so I decided to take a different approach. I had the installation media for an unmanaged copy of SEP that I installed on the server. From there, I opened the SEP manager, went to clients, and exported the communications settings into a file I named “sylink.xml”. Then I copied the sylink.xml file to the server here and opened the SEP client. Inside Help & Support, click Troubleshooting, and then import communication settings. This tells the client where to look for management. After waiting for a minute or two, I went back into Troubleshooting and saw that the client was looking in the correct location for the server policies.