Troubleshooting 101 with the Windows Event Viewer

Troubleshooting 101 with the Windows Event Viewer

Troubleshooting 101 with the Windows Event Viewer

Problem Solving sign with clouds and sky backgroundAs part of my role as a technical writer and user advocate at STORServer, I need to understand and document changes in behavior between different versions of our software. While doing that recently, with STORServer Console (SSC), I decided to uninstall the latest test software from engineering and install an earlier, released version of SSC (V3.1.1) on my machine.

My first mistake? Attempting to roll back an installed SSC version to an earlier version without first completely removing my existing version, including the newer SSC database. (The SSC uninstall program purposely does not remove the database for obvious reasons.) Consequently, after uninstalling my test version and installing the (older) released version, I immediately encountered error messages that seemed to be related to the database. Also, an underlying, and as yet undiagnosed, issue with SQL not restarting after the post-uninstall reboot was contributing to the problem. But I didn’t know that at the time.

I decided to start over with a “clean” system. So I went to the STORServer Knowledge Base ( to find and use an article that I had previously published on how to completely remove SSC from your system. If you’re curious, it’s article #755 – How to completely uninstall STORServer Console (SSC).

After uninstalling the SSC kit, I proceeded to open a command prompt window and enter the commands specified in the article for deleting the database. I got an error that stated that the database could not be found. Oh-oh. That can’t be good!

Working through system problemsTo find out what was up (or down, in this case) with SQL Express, I opened the Windows Event Viewer and filtered the log messages to show only those from MSSQL$SQLEXPRESS (SQL Express). The last message stated “SQL Server is terminating because of a system shutdown.” Dead silence after that. Apparently, SQL did not restart after my post-uninstall reboot. That explains why the database could not be deleted. SQL was not running.

I then used the Windows Services Manager to check the current state of the SQL Server (SQLEXPRESS) service, and sure enough, it was “Stopped.” I restarted the service and then used SQL Server Management Studio to verify that I could connect to the \SQLEXPRESS instance. Success!

Back in the command prompt window, I re-issued the series of commands to delete the SSC database. It worked like a charm this time. Whew! I’m on a roll now!

The next step in the KB article said to delete the leftover install directory. Because I use a trial license while testing SSC software, I moved my license file to the desktop before proceeding to delete the SSC install directory and its contents. And finally, I deleted the user-specific application settings. Now my system was truly “clean.”

At this point, I abandoned the idea of rolling back SSC and decided to install the latest, still-in-development SSC kit from engineering. After starting SSC and adding my local SSC server to the SSC configuration, I encountered another error (something like “No servers responded at startup.”). Huh? Back to the Event Viewer to see what was going on…

Messages issued by STORServer.SscServer revealed that the SSC server had started, but a warning message indicated that SSC was unable to retrieve license information. Oops! I forgot to move my trial license file back into the SSC install directory. (My bad.) Once the license file was back in place, and the SSC server was restarted (to acknowledge the valid license), I added a couple of test TSM servers to my configuration, and all was well.

Moral of the story:

Always check the Windows Event Viewer when troubleshooting!

Nine times out of ten, messages in the Event Viewer will reveal the cause of whatever issue you are experiencing with SSC, SQL, and so on. If I had checked there to begin with (after the initial install of the older, SSC V3.1.1 software), I’d have discovered that SQL was not running, and probably avoided much of the ensuing chaos. The Event Viewer also made me aware of the missing license file.

On to troubleshooting why SQL didn’t restart after the reboot like it should have. When I ask engineering for help, the initial response will probably be: “Did you check the Event Viewer?” Just another day in the life of a tech writer!