Link to home
Start Free TrialLog in
Avatar of DavidBCS
DavidBCS

asked on

Recurring SQLVDI errors in Event log

Ever since we installed Windows Sharepoint Services 3.0 on our system, we have been getting the following errors in the Application Event Log on our MS Windows Server 2003 SBS Standard box. As part of the installation for WSS 3.0, we had to install SQL Server 2005 SP2. These errors as listed below didn't start showing up until after that installation. All other services are working fine, I am not having any difficulty running backups or using my SQL databases. This appears to be more of an annoyance, but I would like to clear it since it is creating grief with our monitoring solution. We've also already applied the hotfix that was provided by MS in KB article 934396 (http://support.microsoft.com/kb/934396/en-us).

Here's the content of the Event log error message:

Event Type:                           Error
Event Source:      SQLVDI
Event Category:      None
Event ID:                           1
Date:            3/3/2008
Time:            9:07:18 AM
User:            N/A
Computer:                           MAINSERV
Description:
SQLVDI: Loc=CVDS::Cleanup. Desc=Release(ClientAliveMutex).
ErrorCode=(288)Attempt to release mutex not owned by caller.
. Process=9560. Thread=3128. Client. Instance=SHAREPOINT. VD=.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This error message also comes in groups of nine successive failures, all that read the same and occur every 15 minutes.

Anyone seen this before or know of a fix/workaround?
Avatar of zephyr_hex (Megan)
zephyr_hex (Megan)
Flag of United States of America image

are you running symantec backup exec?
Avatar of DavidBCS
DavidBCS

ASKER

Yes, we are running SBE v11d for SBS Standard. It also installed SQL Server 2005 and we were not getting these errors post install. It wasn't until WSS 3 and the post SQL 2005 SP2 install that these started showing up.
Try deactivating (unchecking) the AOFO ("Advanced Open File Option" ) for that particular backup job.
SQL resources should ideally not be backed up with the AOFO option enabled. If you need AOFO to back up another resource, then put SQL backups in their own backup job without AOFO.
I'll try that. But, let me ask you this, why would the errors continue to show up in the Event log throughout the entire day even when the backup job has long since been completed?

Thanks...
ASKER CERTIFIED SOLUTION
Avatar of DavidBCS
DavidBCS

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Why would you apply a SQL2000 hotfix when you never mentioned that was part of your configuration?  Did you have an instance of SQL 2000 installed as well?
Prior to R2 release of SBS, Sharepoint Services version 2 is utilized for the management ASPs. When installing WSS 3, one must maintain the original WSS 2 installation in order to preserve the built-in management features of SBS. SBS was utilizing SQL 2000 for Monitoring and Reporting, WSS 2.0 and was later utilized by each successive instance of Backup Exec until version 12. This was not a problem with the original installation with respect to the SQLVDI errors. They appeared after the installation of WSS 3 and SQL 2005. The presence of WSS 2 is already known to anyone who runs, uses, or installs SBS and therefore did not need to be mentioned especially since it was not a factor initially. It is standard troubleshooting practice to look at the last changes in the environment to determine where the fault might be. The error logs were telling me that the problem was with a Sharepoint instance, just not which instance. Given that I had just installed WSS 3 with SQL 2005 and these problems started appearing, I naturally presumed to think that it was the latest instance. I even mentioned this much in the original posting as I had already applied a SQLVDI hotfix that related to SQL 2005. As it ended up turning out, MS had a specific hotfix for this issue which was not known or available when the problem first appeared. Extensive research, problem solving, and troubleshooting on my part revealed the solution.

Thanks...
Thanks for the clarification David, that makes perfect sense.