I had a very frustrating issue with a WSS environment recently. This was a single server deployment, using WSS, the Windows Internal Database (a special edition of SQL Express 2005). Things had been going well until one day the Windows Internal Database service stopped working. Browsing to the web site would result in a "Cannot connect to the configuration database" message.
Trying to restart the Windows Internal Database service failed. The event logs on the server had error codes 17182, 17826 and 17120. The details of these errors were missing from the logs, but I was able to track them down by going to the Windows Internal Database logs at C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\log:
2009-10-21 10:54:21.10 Server Error: 17182, Severity: 16, State: 1.
2009-10-21 10:54:21.10 Server TDSSNIClient initialization failed with error 0x5, status code 0x90.
2009-10-21 10:54:21.10 Server Error: 17182, Severity: 16, State: 1.
2009-10-21 10:54:21.10 Server TDSSNIClient initialization failed with error 0x5, status code 0x1.
2009-10-21 10:54:21.10 Server Error: 17826, Severity: 18, State: 3.
2009-10-21 10:54:21.10 Server Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
2009-10-21 10:54:21.10 Server Error: 17120, Severity: 16, State: 1.
2009-10-21 10:54:21.10 Server SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.
Doing searches on the interweb suggested that I re-install SQL Server, as there may be corruption in the registry. Since I was dealing with the Windows Internal database, I didn't really have the option to re-install just that component. Some newsgroup posts suggested looking at what registry entries the database server was trying to access.
My Windows Internal Database was running as the Network Service account. As a quick test, I added this account to the Local Administrators group. I was then able to restart the Windows Internal Database service. This confirmed that my issue was related to permissions. It is definitely not a good idea to give Network Service this level of permissions, so I took it out of the Local Administrators group and moved on to the next stage.
I downloaded Process Monitor from Microsoft. This tool replaces the old RegMon and FileMon utilities. I configured it to filter for Registry events with a Result of ACCESS DENIED. I then tried to restart the Windows Internal Database Service via the Service Manager console. Sure enough, I found that the Network Service account was being denied access to HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MICROSOFT##SSEE\MSSQLServer\SuperSocketNetLib. Why did it no longer have access to this? I have no idea. My suspicion is a Windows Update modified permissions, but I can never prove that in a court of law.
I dropped into RegEdit and granted my Network Service account full control to this registry location. I then restarted my Windows Internal Database service and everything worked perfectly.
