After several administrative steps over a few months, we suddenly found the following error coming from an instance of SQL Server on a virtual machine:
Your SQL Server installation is either corrupt or has been tampered with (unable to load SQLBOOT.DLL). Please uninstall them re-run setup to correct this problem.
Nobody had been keeping an eye on it, because the virtual machine gets very little use from day to day, but then is suddenly essential and has to have the dust blown off it. So we set to the nasty nuts-and-bolts work of starting/stopping services, running uninstall scripts, fixing registry entries when the scripts couldn’t be found, etc. All very well, but when we finally were able to begin the uninstallation procedure, it promptly keeled over, probably because it too was trying to activate some other “unloadable” .DLL .
It turns out that relabeling the drive that an installed SQL Server instance sits on (in this case, from F: to E:) causes all sorts of problems: even, it seems, if you scour the registry for old instances of F:SQL_Server... and replace with E:SQL_Server.... Moving it back fixed it. This suggests that if you want to relabel the drive, you have to completely uninstall SQL Server first. If you’re clever about it you can keep your databases and reattach them when you reinstall SQL Server on the new drive.
(I only mention this here as lots of other methods—which don’t work—seem to have a lot of Google juice, and we couldn’t get past the uninstallation barrier.)
