Results 1 to 5 of 5
  1. #1
    Join Date
    Apr 2002

    Unanswered: SQL Server is not releasing Extended SP DLL

    During a Wise Installation upgrade of our software, we are renaming a
    directory that contains our ExtendedSP DLL. We issue a
    DBCC TSWSQLXP(Free) call before doing the rename, yet SQL Server,
    still "holds on" to that DLL. We install a new version, and the ListDLLs
    utility (from sysinternals) lists the new DLL in the correct directory.

    However, when trying to remove the renamed directory, it won't let us
    remove the old DLL because it says it is in use. We can delete the NEW
    DLL in the NEW directory with no problem.

    I have run the DBCC call numerous times and SQL Server STILL won't
    release the DLL for deletion. The only way to delete the OLD DLL is to
    stop the SQL Server, delete the DLL, and then restart SQL Server. We
    do NOT want to do this because there may be other processes running in
    SQL Server.

    Any help here would be greatly appreciated.

  2. #2
    Join Date
    Jan 2004
    In a large office with bad lighting
    That extended sp is not a microsoft product. It was probably written by your vendor, and as such you will have to work with them to figure out why it fails.

    Edit: That is not a valid DBCC command either,

    -- This is all just a Figment of my Imagination --

  3. #3
    Join Date
    Apr 2002
    Quote Originally Posted by tomh53
    That is not a valid DBCC command either,
    Oh, but it is, from BOL:

    DBCC dllname (FREE)
    Unloads the specified extended stored procedure dynamic-link library (DLL) from memory.

    Our dllname is TSWSQLXP.

    If it weren't, we'd get error messages and I can run that in Query Analyzer
    just fine.

    The ExtendedSP was written by us and we've never had a problem with this
    before. But then again, we've never renamed the directory before.

    Here's the process inside our installation routine:

    1. Drop Extended Stored procs
    TSWSQLXP.dll }
    3. Rename BIN directory to BINxxx (where xxx = our software version)
    {We rename the BIN directory to restore files in case of errors during
    4. Install NEW TSWSQLXP DLL into new BIN directory
    5. Install Extended Stored procs
    6. Call one of the newly installed Extended Stored procs
    7. Delete renamed directory (fails because OLD TSWSQLXP DLL still in use
    manual delete fails, also)

    We ARE able to delete NEW TSWSQLXP DLL from the new BIN directory even
    though the references in the Extended Stored proc point to the NEW
    , using the SQL:
    select  name =, dll = substring(c.text,1,255)
            from master.dbo.sysobjects o, master.dbo.syscomments c
            where =
            and o.xtype = N'X '
            and [name] like 'xp_SY%'
    {ALL our EXPs begin with xp_SY...}

    Also, even using MoveFileEX with the MOVEFILE_DELAY_UNTIL_REBOOT flag
    won't allow the directory to be deleted when the system reboots. I have
    double checked the registry key
    Control\Session Manager\FileRenameOperations) and it is correct.

    Any other ideas???

  4. #4
    Join Date
    Apr 2002
    I can also use the ListDLLs utility mentioned earlier and it shows that sqlserver is STILL using the ExtendedSP DLL even though I issued the DBCC call, yet it's reference is pointing to the NEW DLL.

  5. #5
    Join Date
    Jan 2003
    Provided Answers: 11
    I can run this in Query Analyzer with no error message, but I doubt it did anything:
    dbcc mcrowley_is_great(free)
    BOL says nothing about what messages are returned on failure, only success. One thing to mention is that the DLL name is probably very case sensitive. Make sure you have the right cased spelling by running sp_helpextendedproc to see what SQL Server lists for it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts