Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2000-12-22
2004-05-18
Beausoliel, Robert (Department: 2114)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S045000, C717S124000
Reexamination Certificate
active
06738932
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates, in general, to systems and methods for determining at a particular operating time, e.g., at the time of a crash, the version of software executing on a computer system, and, more particularly, to a software identification system and method for use in dump analysis for identifying from a memory image which version of kernel or other software was running on a computer system at the time of a system crash.
2. Relevant Background
Computer system designers and analysts face the ongoing and often difficult task of determining why a computer system stopped operating or is failing to operate as designed. When a problem or error condition in the computer system is serious enough to stop or interrupt the execution of a running program, this failure is known as a crash. To assist in system analysis, a crash or memory dump is performed when a computer system crashes to generate a memory image of the existing state of software executing on the system at the time of the crash and of other system-related information. In this regard, the system-level commands or programs in the operating system, i.e., the kernel software, is of particular interest to system analysts in debugging a crashed computer system. For example, in an UNIX®-based system, the kernel is the program that contains the device drivers, the memory management routines, the scheduler, and system calls. Often, dump analysis begins with analysis of these executables. Dump analysis, which includes inspection of the memory image for the cause of the crash, is a difficult and time-consuming task due to the large quantity of information contained in the dumped memory image.
The task of identifying and correcting the cause of the problem in the currently running software is further complicated because the person or mechanism performing the dump analysis usually needs to first identify what version of kernel (or other) software was running on the computer system when the crash occurred and the memory image was created. In this regard, dump analysis often requires properly matching machine code or executables present in the crash memory image to the source code that created the machine code to identify programming problems and errors. This matching process can be a time-consuming and nearly impossible task without knowledge of the versions of software the computer system was running.
Typically, after a version of kernel or other software is installed in a computer system, updated versions and patches (i.e., small additions to the original software code to bypass or correct problems) become available from the software provider and are installed by the system operator. The installation of these updates and patches often are not recorded, such as by entering them into a software management system. Additionally, the system operator may modify the received software with or without the permission of the software provider and may fail to notify the software provider what modifications have been made to the system software. Consequently, there is a need for an effective way to identify the version of software running on a computer system, especially at the time of a system crash, to improve debugging and maintenance of system software.
While providing some useful version information, existing techniques of identifying the version of software running on a computer system do not effectively meet the need of computer system analysts. One technique involves inspecting the ondisk records created when the running software was installed, but this is only useful if software or package management applications were properly installed and used by the system operator during system configuration changes. Another identification technique involves comparing the crash memory image with a stored or ondisk file from which the running software was loaded into the computer system. Often, this stored file is not provided to the analyst as part of initial dump analysis and typically requires the system operator, who is a customer of the analyst and software provider, to take actions (such as software verification steps) to assist in the dump analysis. Clearly, it is desirable to avoid burdening a software customer with additional actions when their computer system has crashed due to a problem with the software provided by the analyst or their company. For this reason, it is also typically not desirable to try to identify software versions by requesting the system operator or customer to print a revision or patch list. Additionally, such a patch list may not be accurate because the software, e.g., kernel binary, may have been updated without recordation and/or the system software configuration may have changed from the crash configuration by the time the patch list is generated by the customer.
Hence, there remains a need for an improved method and system for identifying the version of software, such as kernel software, running on a computer system. To improve the effectiveness of dump analysis, such a method and system preferably would be configured to be useful for identifying versions of kernel software running on a computer system at the time of a computer system crash causing a memory dump (i.e., generating a crash memory image).
SUMMARY OF THE INVENTION
The present invention addresses the above discussed and additional problems by providing a software version identification system that effectively and efficiently isolates and then identifies software (e.g., executables) in a crash memory image to identify the versions of software running on a computer system. Generally, the identification system includes an indexing mechanism that operates to create a comparison file containing signature information for a set of executables that may be run on the computer system. The signature information includes a total size in bytes of each executable and includes offset and byte length information and a checksum for executable text segments (i.e., segments of the executable that are typically not altered during execution of the software) in the executable, and additional version identification information (e.g., version name, patches included, and the like). The identification system also includes an identification mechanism configured to process memory images from the computer system to determine the size in bytes of executables in the memory image. The identification system is further operable to index into the comparison file to find executables that have the same total size. Positive identification of software is achieved with the identification mechanism by comparing at each matching offset the lengths of executable text segments the signature information and for the executable in the memory image. Positive identification of software is achieved with the identification mechanism by comparing each checksum in a signature with checksums calculated from the memory image at the same offsets and lengths of executable text segments in the signature.
According to another important aspect of the invention, a method is provided for identifying software executing on a computer system from a memory image that defines at a particular time a state of the executing software. The software identifying method includes populating a comparison file for the computer system with executable signatures. The executable signatures correspond to a number of preselected executables that can be run on the computer system, such as specific portions of kernel software, and include for each preselected executable version identifying information. The method continues with locating executables in the received memory image. Next, the located executables are processed to generate comparison information for each of the located executables. To identify which of the preselected executables are operating on the computer system at the time the memory image was created, the method continues with comparing the comparison information to the version identifying information, with matches providing positive identification of softw
Beausoliel Robert
Chu Gabriel
Hogan & Hartson LLP
Kubida William J.
Lembke Kent A.
LandOfFree
Method and system for identifying software revisions from... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for identifying software revisions from..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for identifying software revisions from... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3233688