SQLVDI: Loc=SignalAbort. Desc=Client initiates abort


  • We are seeing this happen rather frequently on our production servers


    Windows 2003 Enterprise with SP 2

    SQL Server 2005 Enterprise with SP2


    This is on a Windows Cluster for high availability


    Message Text - in order of occurance in the event log

    SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=2992. Thread=5064. Client. Instance=METIS. VD=Global\VDI_585DBB67-19E7-4FC2-8FAF-1DD9AF2ACFBD_0_SQLVDIMemoryName_0.


    SQLVDI: Loc=CVDS::Close. Desc=Abnormal termination state. ErrorCode=(0). Process=2992. Thread=5064. Client. Instance=METIS. VD=Global\VDI_585DBB67-19E7-4FC2-8FAF-1DD9AF2ACFBD_0_SQLVDIMemoryName_0. 


    SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=5020. Thread=4592. Client. Instance=METIS. VD=Global\VDI_A5EA7805-F8C1-4856-B2F7-07436CEE8742_0_SQLVDIMemoryName_0. 


    SQLVDI: Loc=CVDS::Close. Desc=Abnormal termination state. ErrorCode=(0). Process=5020. Thread=4592. Client. Instance=METIS. VD=Global\VDI_A5EA7805-F8C1-4856-B2F7-07436CEE8742_0_SQLVDIMemoryName_0.

    We are running native SQL Backups when this happens.

    This seems to happen on a regular 7-8 day period.


    Server shuts down and even clustering is taken off line and lost.

    Any help would be appreciated.



    Wednesday, August 06, 2008 3:24 PM

All replies

  • SQLVDI errors generally point to an external application taking a backup.  Are you certain that there isn't a External process running to take a weekly backup?  If the problem is fairly predictable, try to catch it with a Trace, either server side or with profiler.  Make sure that you are logging the Client ProcessID and Hostname.  When you catch the error, try to correlate the processID with the PID on the host making the call in Task Manager.


    Wednesday, August 06, 2008 9:48 PM
  • One thing I forgot in my original post, this is happening on the IA64 platform, if that makes any difference.


    Server - HP Integrity 8640


    As for the external process, the only external processes at the time were the hooks for monitoring software, in our case, Quest Spotlight.


    The thing that is most perplexing is that this error not only halts SQL Server, but it also crashed both the cluster and the OS.  In the end the server crashed and nothing ever moved to the cluster partner.


    Outside of the log entries posted, there are or were no other salient log entries. The entires prior were Transaction Log backup successful for database XXX


    On the other side is eventlog stopped for unkown reason, then event log started.


    Only in this instance was I able to even capture the SQLVDI events.  In prior crashes, these never even made it into the event log.



    Thursday, August 07, 2008 7:23 PM
  • You aren't using Lightspeed as a part of the Quest package for your backups?  I know you say you are doing native backup, but I am double/triple checking this since VDI is the Virtual Device Interface for backup/restore.  It would be possible that VDI isn't the problem at all, it just coincided with the problem this one time.

    Thursday, August 07, 2008 7:27 PM
  • Litespeed is installed, but not in use just yet.  The backups are done through a SQL Server Maintenance plan, not a Litespeed one.

    Thursday, August 07, 2008 7:35 PM
  • I am getting the same message when running SQLSafe/SQL Server backups. The situation is occuring on a HA cluster with W2003 64bit enterprise edition with SP2. sql server 2005 enterprise with sp2. The next message is


    SQLsafe Backup Service version 4.7.727.5192:
    Backup of database TSS failed at 10/21/2008 3:08:21 PM due to Server instance: WPG-SQL2K5P1-20, Database: TSS
    [SQL Native Client]SSL Provider: The Local Security Authority cannot be contacted
    [SQL Native Client]Client unable to establish connection



    SQLsafe Backup Service version 4.7.727.5192:
    Timeout configuring virtual device set.  (COM error code 80770003)


    These messages have occured on two separate occasions.



    Tuesday, October 21, 2008 8:49 PM
  • We started getting these errors having upgraded from litespeed 4.8.3 to 5.0.1


    At this point Quest deny there is a problem. They told us to reregister SqlVdi.dll. We did but the errors occurred again after 24hrs.


    We have downgraded back to 4.8.3


    Friday, December 05, 2008 10:44 AM
  • Hi everyone,


    I too am getting similar SQLVDI errors in the Event Viewer under "Application" for a client's Win2003 Small Business Server.


    One of my attempts to fix the problem was to register SQLVDI.dll as per the following article:


    The backup that ran after I did that worked fine, but since then the same problem has reared its ugly head again. I tried the same process of registering the SQLVDI.dll file, but it didnt work the second time.






    Wednesday, December 10, 2008 10:42 PM
  • Try HyperBac for SQL Server, same benefits for compression/speed as LiteSpeed and others however implements backup compression as a file system filter and does not use VDI
    Tuesday, December 23, 2008 11:14 AM
  • Has there been a solution posted to this problem?  I have a production Windows 2008 / SQL 2005 64bit server experiencing this same problem. This is a 2 node active cluster.
    Tuesday, December 01, 2009 7:28 PM
  • I too am having the same issue.  I am running windows 2003 sp 2/SQL 2005 SP 2. I am using Symantec BESRM 8.5.  I have run all suggested solutions to no avail.
    Wednesday, December 02, 2009 5:02 PM
  • I am also facing the similar error. I am using Quest Litespeed 5.0.1 on Windows 2003 Server for SQL Server 2000.

      SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=8476. Thread=1028. Client. Instance=Prod_SQL1. VD=Global\VDI_FB7A53C0-02D2-4469-A676-

    It occurs during  on Litespeed backup

    Sivaprasad S Please click the Mark as Answer button if a post solves your problem!
    • Proposed as answer by jeffreyaven Thursday, March 25, 2010 6:43 AM
    Thursday, March 25, 2010 3:23 AM
  • We were able to resolve our problem by removing the server alias from Configuration Manager.  Not sure why, but we had an alias configured for the local named instance.

    Thursday, March 25, 2010 12:29 PM