August 4, 2003 at 4:12 pm
Hello all.
I am the de facto SQL Server administrator at my place of employment. We had a problem with one of our systems running SQL Server 7 (SP 3) today. Nobody could connect to this SQL Server 7 instance -- the error message was "Timeout expired".
There was one conspicuous message in the event log and the SQL Server log, referring to an extended stored procedure named xp_qv, being run by xpsqlbot.dll. I am not familiar with either of these xp* names.
We (one of our network/server administrators and I) decided to reboot and do nothing with SQL Server (no starting of any dependent services, etc.) immediately after reboot. We logged in after the reboot and observed that SQL Server started (the tooltip over the SQL Service Manager said "SQL Server -- Running"), but even SQL Server Enterprise Manager, running as Administrator on this server, could not connect to the server (same "Timeout expired" error). We continued searching the registry (found nothing of interest), searched for the file named xpsqlbot.dll (which we found), and tried to identify all the processes that were running. Meanwhile, I tried to connect through Enterprise Manager again and it worked.
The SQL Server log shows 21 minutes between the time that xpsqlbot.dll was used to execute xp_qv and the time that xpstar.dll was used to execute sp_MSgetversion.
I searched Microsoft's support database for xpsqlbot -- nothing. Microsoft's public newsgroup for SQL Server contained a few messages that referred to xpsqlbot in a SQL trace dump. Other than that, I've got nothing with regard to xpsqlbot or xp_qv. They seem to be non-standard, and I suspect we've been hacked.
We know we need to go to SQL7 SP 4, and we will do that soon. However, some questions that I thought I'd ask all of you:
(1) Any idea what xp_qv or xpsqlbot.dll are? Have any of you encountered either or both before?
(2) How can I determine why this extended stored procedure running when SQL Server is started after the server machine is restarted?
(3) How can I prevent this stored procedure from running when SQL Server is started?
(4) If it is supposed to be there, and I wanted to remove it just to test a theory, how would I put it back?
(5) Assuming this stored procedure is the problem, any ideas why running this stored procedure would prevent all users from connecting to the database? I could understand if I was getting database lock errors from running a query, but this is just the initial connection to the database that I suspect is being blocked by the execution of this stored procedure.
(6) I suppose I've been assuming that xpstar.dll running sp_MSgetversion at SQL Server startup is standard startup behavior. Is it?
Thanks in advance for any and all suggestions, as well as your understanding that I am an application developer wearing a SQL Server administrator hat, and the hat isn't fitting very well at this moment.
Regards,
Dan
August 4, 2003 at 4:37 pm
Found a ref that says its nothing to worry about:
What does the log say? Its possible that the system was still in recovery and thats why you got the timeout. 21 mins is long, but if you had a really bad shutdown, its possible. Got enough disk space? Anyone made any changes
Andy
August 6, 2003 at 9:32 am
Andy,
Thanks for the response. I was in meetings most of the day yesterday.
The log doesn't say anything extraordinary, just that it is running xp_qv from xpsqlbot.dll. We are looking at disk space as an issue on this system (C: drive is ~75% full). The system administrators and I have not made any major changes to this system. However, others do have access to make changes -- this server hosts a number of applications.
I'm relieved to know that it is a Microsoft dll, albeit an undocumented one. I'll be stopping and starting it again sometime this week, just to see if it takes 21 minutes to run xp_qv again.
Thanks again,
Dan
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply