Examining Executables And Dynamic Link Libraries

Part of the job of power users and system administrators is troubleshooting failed systems and application errors. When a system doesn’t work properly and you ask the user what he or she did to cause the problem, you often get the reply, “I didn’t do anything. It just stopped working.” Of course, you and I know better, because a working system just doesn’t stop working for no reason. Often, the cause of the problem is a version conflict with a dynamic link library. This usually occurs when a user installs a program with an outdated file. Or, perhaps, the user installed a system component from the original setup media on a computer with a service pack installed and then didn’t update the system by reinstalling the service pack. In either case, it is up to you to figure out where the problem is and how to fix it.

The first thing you need to do is isolate the problem. Generally, if it is a system-related problem, you can find help in the system event log. Just bring up the Event Viewer, and examine the system log for service startup or failure messages. For an application, a message usually appears when you try and execute the application. These messages usually tell you where the problem resides, but not always. Sometimes it requires a bit of sleuthing on your part. This is where determining the version number of an executable or dynamic link library comes in handy. To find out a version number, just execute the following steps.

1.  Open the Windows NT Explorer.

2.  Browse your disk until you find the application or dynamic link library that you think might be the problem.

3.  Right-click on the file, and choose Properties from the pop-up menu. The [ApplicationName] Properties dialog box should appear, as shown in Figure 11.2.

Figure 11.2  Examining the general properties of an application.

4.  Examine the file’s size, creation date, and modified date. Compare this information with the information returned from a known good version of the file (on another computer, for example). If the information differs, you have probably located the problem.

5.  If the information is the same, or close to it, you may need to dig a little further by selecting the Version tab to display the Version property sheet, as shown in Figure 11.3.

Figure 11.3  Determining the version of an application.

6.  You are looking for two things on the Version property sheet. First, you want to examine the File Version number. Second, you want to examine the Product Version number. Sometimes, these two numbers are the same, other times they differ. If the numbers differ, use the Product Version information. Once more, you want to compare this information with the information returned from a known good version of the file. If the information differs, you have located the problem.

Once you have located the problem you have two choices—either copy versions of the file from the known good system to replace the outdated version or reinstall the application. I normally just copy the relevant files, unless there are too many files to examine and copy (in which case, I just reinstall and get it over with). The only time a reinstall might not work is when the file version is greater than the replacement file. Usually, this is caused by installing beta software on a computer. Should this occur, you will need to delete or rename the offending file(s) before you can reinstall the application.

Summary

In this chapter, we examined the Windows NT directory structure. Hopefully, this information answers your questions about where various application and system files are located and aids you in your day-to-day activities. We also examined how to determine a file’s basic property and version information to help resolve any version conflicts. While version conflicts do not occur every day, it is helpful to know how to resolve them when they arise.