Method, system and device for validating repair files and repairing corrupt software

A system and method for repairing corrupt software components of a computer system. Corrupt software is detected and repaired utilizing an automated component repair service. Repair files are downloaded from an external storage location and used to repair the corruption. The downloaded files are preferably the smallest amount of data necessary to repair the identified corruption. The process of repairing corrupt files is used in conjunction with a software updating service to resolve problems that occur when corrupt software is updated by allowing a corrupt component to be repaired and then uninstalled such that an updated component can be properly installed.

BACKGROUND

Modern computer systems run a complex array of software, from the operating system (OS) to application programs. The OS alone may include tens of thousands of files. Related files may be grouped into software components.

It is known for users of computer systems to update the software installed on their computer systems. Updates may include fixes to bugs or security updates to prevent newly discovered potential attacks. Additionally, updates may release new features that were not included in earlier versions of the software. Regardless of the reason for an update, corrupt software components on the user's computer system may prevent software updates from installing properly.

Such corruption may have any of a number of causes. Corruption may occur because of a virus introduced into the computer system or some other attack by a malicious party. Software mis-configuration and faults in hardware components, such as memory and non-volatile storage, may also cause component corruption.

Regardless of the cause, corruption may block an update from being completed. For example, the WINDOWS® OS sold by Microsoft Corporation includes software updating services that accesses a remote service, called WINDOWS UPDATE®, to install new versions of components of the WINDOWS® operating system. An update by this service often entails uninstalling older versions of components before installing updated versions of those components. If the older versions are corrupt, the uninstall action may not be able to proceed. This will prevent the installation of the updated components, leaving the user with an out of date computer system.

SUMMARY

Improved computer system stability and reliability may be achieved with a method for repairing corrupt software. Repairing corrupt software components, for example, may allow old versions of components to be uninstalled such that updated components can be installed. Improved system stability and reliability may then result from operating the system with up to date components.

Repairing software is important any time that integrity of the software is suspect. For example, if software has been corrupted or is not working properly, the computer system would benefit from repairing the software. In particular, it is advantageous for the method of repairing software to work at the lowest level of granularity possible. For example, if a software component is found to be corrupt and in need of repair, the system should repair only the smallest set of files necessary to mend the corruption.

Regardless of the reasons for repairing corrupt software components, the repairs may be made by detecting corrupt software components and making a list of corrupt files. A set of files needed to repair the corrupt files may be located and downloaded. The corrupt component may then be repaired using the downloaded files.

In some embodiments, file corruption is detected using a hash function and a separately stored hash key. The computer system may then download a set of repair files corresponding to the corrupt files. Some embodiments include an act of validation to ensure that the repair files received by the computer system are authentic and safe to install.

In some embodiments, the method of repairing corrupt files is used in a software update process. If it is determined that a component to be updated is corrupt, the component will be repaired and uninstalled. Only then will an updated version of the component be installed.

In other embodiments, the repair of corrupt software can be triggered manually by a user. Alternatively, it may be triggered by a system health checker, such as an anti-virus software application.

DETAILED DESCRIPTION

The inventors have recognized and appreciated that repairing software components that have become corrupt may facilitate updating of software components executing on a computer system and may result in a more stable and reliable computer system. The system and method presented herein can repair components with minimal involvement of the user. By using an automated repair service, user frustration may be reduced and the user may spend less time addressing issues resulting from failures that occur in the software updating process.

In some embodiments, a component repair service may execute on a computing device. That repair service may operate in response to one or more triggers, such as a failure of an updating service on the computing device to complete an update or an indication from an anti-virus or other anti-malware component indicating a possibly corrupt component or a collection of components, such as a software subsystem. Other triggers may alternatively or additionally be used. In some embodiments, the trigger may be an express request from a subsystem to be verified. In other embodiments, a trigger may be any indication that the system integrity is compromised.

Regardless of the trigger for a repair, the repair service may obtain, from a suitable source, copies of one or more files that are a part of the corrupt component. The obtained files may provide uncorrupted versions of corrupt files that are contributing to the corruption of the corrupt component. The downloaded files may be of the same version as are installed on the computing device and may be used to repair those files, possibly by replacing them.

The suitable source of the repair files may vary depending on the embodiment. In some embodiments, the source is an external server. This external may, in some embodiments, be a trusted source. It may also be validated by a validation process known in the art. It may be a server on the local network to which the computer connects. Alternatively, the source does not have to be a traditional server, but instead could be a peer to peer network source. In some embodiments, the suitable source may be an internal store or disk. The OS may keep a store of software files that may be used to repair software components even when the computer is not connected to a network. As an example, the OS developer may encourage original equipment manufacturers to ship computer hardware with a recovery zone already stored to the computer storage device.

The repaired files may then be used as part of an uninstall operation of the corrupt component. That component may then be reinstalled using uncorrupted files. The same version of the component may be reinstalled based on the repaired files, which may be the case when the goal is to repair corrupted software. Though, in some embodiments, an updated version of the component may be installed, which may be the case when the goal is to update software that was found to be corrupted.

Any suitable mechanism may be employed to identify a set of files corresponding to a corrupt component. In some embodiments, the files may correspond to a subset of the corrupt component. To identify this subset, files as they exist on the computing device may be tested to determine whether any have been corrupted. Such testing may entail using a hash function and comparing one or more hash results associated with files of the component to corresponding hash results of uncorrupted files to identify any deviations signifying corruption.

The hash results for uncorrupted files may be obtained from any suitable source. In some embodiments, a software component may be implemented with one or more packages that each includes both a manifest and a payload. The payload may be made up of files that contain computer executable instructions that are executed to perform functions of the component. The manifest may identify the files that form a part of the package and may additionally store an expected hash result for each file. Corruption may be detected, in a file, for example, by computing a hash result for the file as it exists on a computing device and comparing the computed hash result to the result in the manifest.

In some embodiments the validity of the manifest may also be checked to ensure that the hash results for files in the package or other portions of the manifest have not been corrupted. Such a check may be performed before the hash results for individual files stored in the manifest are used to test the files such that the manifest may be repaired prior to use to test the payload files. A check of the manifest may be based on a hash result stored on the computing device at the time the component was installed. For example, some operating systems employ a database, which may be called a “registry,” to store information about software or hardware components installed on a computing device. Upon validating a package upon install, for example, an installation of a component may write into the registry a hash result value for each manifest associated with the component. This hash result value may be used to subsequently identify any corruption of the manifest.

Such an approach to testing the manifest and payload files separately allows portions of the component that need to be repaired to be identified and then obtained from a trusted source. Though security techniques could be used on a computing device to maintain a trusted store of back-up copies of components installed on the computing device, in some embodiments, the trusted source of components may be a server or other device external to the computing device. In some embodiments, the source of the files used to repair corrupt files on a computing device may be an update server, such as the WINDOWS UPDATE® server in computers with the WINDOWS® operating system.

Update servers conventionally provide entire packages for the computer system to download. These packages can be large and utilize a significant portion of the computer system's available bandwidth. In order to support repair of corrupt software component, an update server may allow the computing device to limit its download to the necessary files to repair the corrupt components, rather than downloading an entire update package.

The files that are downloaded can be in any suitable form. In some embodiments, only the smallest piece needed for repair is downloaded. The smallest unit available to download can be any size unit of the overall software environment being repaired. The smallest unit being downloaded may be the entire component, an individual file, or even a portion of a file that needs repair. The files downloaded need not be in any particular format. In some embodiments, the files may be encoded or encrypted. In other embodiments, the entire file may not be downloaded, but just a portion of a file.

In some embodiments, a mapping may be required to relate a specific file on a computing device to a specific unit of content that may be accessed on an external server. For example, an update server may organize files into components, which are in turn placed into packages, which are in turn organized by versions. A mapping between an identified faulty file and a unit of content that can be provided by a update server or other trusted source may be made to determine an appropriate unit or units that contain files to repair the corrupt files on a computing device. This mapping may be performed in any suitable location, including on the computing device, on the external server, or partially on each.

With reference toFIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer110. Computer110is an example of a computing device that may selectively repair components of an operating system or other software on the computing device. Components of computer110may include, but are not limited to, a processing unit120, a system memory130, and a system bus121that couples various system components including the system memory to the processing unit120. The system bus121may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

The computer110may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer180. The remote computer180may be a personal computer, a server, a router, a network PC, a peer device or other common network node. Remote computer180may be an example of an update server.

Remote computer180typically includes many or all of the elements described above relative to the computer110, although only a memory storage device181has been illustrated inFIG. 1. The logical connections depicted inFIG. 1include a local area network (LAN)171and a wide area network (WAN)173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

FIG. 2illustrates portions of the computer environment200that are relevant to some embodiments of the invention. A computer system210has at least one processor214for executing software. The software may include operating system (OS)134, application programs135and other program modules136, as illustrated inFIG. 1. Though, it should be appreciated that the type of software executing on a computer system210or repaired is not critical to the invention.

The processor214is connected to at least one storage device220. This storage device may be volatile memory, such as RAM132, non-volatile memory141, such as a hard disk drive or flash memory, or a combination of non-volatile and volatile memory. The storage device stores multiple software components240,250,260and270. Each software component240,250,260and270is a collection of individual files that are related to one another. Here, a “file” may be an organized grouping of digital data stored in a predefined format in memory allocated by a file management component (not shown). Though, it should be appreciated that a “file” may be any suitable collection of data that may be manipulated, and the specific structure of such a “file” is not critical to the invention.

In the illustrated example, component270comprises payload files272/274and a metadata file276, which may in some embodiments be implemented as a “manifest” of a component. Payload files are files that are used by the processor214of the computer system210while executing the component270. These files may include executable files, which may sometimes be formatted as dynamically linked libraries (DLL). The metadata file276stores information about the payload files, such as details regarding dependencies between executables of component270. For example, if payload272depends on payload274, this will be explicitly recorded in the metadata file276. The present invention is not limited to the aforementioned file types. Files of any suitable format may be supported and the format of the files may depend on the component being repaired.

The metadata file276also stores information allowing the payload files to be tested for corruption. In the illustrated embodiment, that information is in the form of one or more hash keys278for a hash function228, which is also stored on the storage device220. The hash key278is the result of operating hash function228on an uncorrupted version of payload274. The hash function228is a computer-executable component that may be applied to a file to generate a hash result. This hash function228is preferably cryptographically secure, but is not required to be so limited. If the hash function228is performed upon a corrupt version of the payload274, then the value that results from the hash function will differ from the stored hash key278. This difference acts as a clear indication that the payload file274has changed in some way—and potentially in a manner that is harmful to the computer system210.

The metadata file276itself may also become corrupt. Thus, it is useful to have a hash key232stored somewhere on the system. An example of a suitable location for storage of the hash key232of the metadata file276is in the registry230.

Though, it should be appreciated thatFIG. 2represents just one example of an arrangement of information that allows corrupt files to be identified. In some embodiments, it is possible for the metadata to be incorporated into the payload file274such that there is no need for a separate metadata file276. In this case, the hash key278may be embedded in the payload file274along with the rest of the metadata.

The storage device220also stores a component repair service222. This may also be a piece of software that is preferably part of the OS134, but may be a separate application program135. The operation of the component repair service222will be discussed in conjunction withFIG. 3, which details an embodiment of a method to repair a corrupt software component.

The component repair service222may be initiated302in any one of several different ways. In some embodiments, it may be started by a user101that manually runs the component repair service222. In another embodiment, the component repair service222may be activated by a system health checker, such as an antivirus program226, in response to detecting a potential corruption. In yet a further embodiment, the component repair service222may be executed due to a failure in a software updating service224. As already mentioned, in some cases software component270cannot update to a new version properly if it has become corrupt. Thus, the corrupt component270may be repaired by the component repair service222prior to the software update service224completing an update.

It should be appreciated that an update is just one example of a scenario in which a repair of a corrupt component may be performed. Examples of other scenarios include a software subsystem requesting to be verified. In some embodiments, repair of a corruption may be performed based on an indication from a system health checker that a potential corruption was identified. Other embodiments may choose to repair corrupt software based on any indication that the software is not working properly and causing the integrity of the system to be compromised.

As described herein, the repair service222and updating service224are separate components. In some embodiments, however, the repair service222may be a portion of the updating service224. Such an embodiment may rely on existing features for accessing an external update service and suspending access to software components and any other operations that are similarly performed by the repair service and updating service.

Regardless of type of event that triggers operation of component repair service222, once the component repair service222has been initiated at act302, it will detect corrupt components at act304. This may be accomplished with the hash function228, as illustrated in more detail inFIG. 6. The process inFIG. 6is initiated at602by the execution of the component repair service222. As part of the illustrated process, component repair service222runs the hash function228on a file274that is part of the component270being tested at act604. The file may represent a payload file274, a manifest file276or any other suitable file. The hash value that results from operating the hash function on the file is then compared at act606to the stored hash key232in the case of a file containing a manifest276or key278in the case of a payload file274. If the generated hash value does not match the stored hash key278, then the file is different than the originally installed file, which is an indication of file corruption.

At act608, the component repair service222checks whether there are more files to be evaluated. If there are more files to be evaluated, then it will loop back to repeat the process of hashing the next file at604and comparing the hash value to the hash key at606. If there are no more files to check, then component repair service222will end the detection of corrupt components at act610.

Whether there are more files to be evaluated may be determined in any suitable way and may depend on what event triggered operation of component repair service222. In some embodiments, every component240,250,260and270of the computer system210will be checked for corruption. In other embodiments, only a selected set of components will be tested. For example, if a system health checker, such as an antivirus program226, indicates that a specific component is possibly corrupt, then the detection of corrupt components in act304may only be run for the flagged components such that only the files of those components are evaluated in the process ofFIG. 6.

Regardless of which files are evaluated in the process ofFIG. 6, the results of those evaluations may be used in the process ofFIG. 3. At act306, the component repair service222determines a set of corrupt files that need repair. It is at this point that it is determined which of the components and files that were detected as corrupt in act304should be repaired.

The component repair service222locates a set of repair files294,296and298that will be used by the computer system210to fix the corrupt files at act308. These files may be located, for example, on an external server280.FIG. 5shows one possible embodiment of this act.

The routine starts at act502when the component repair service222initiates act308ofFIG. 3. At act504, the corrupt component270is mapped to a package292. This mapping may allow for identification of appropriate copies of a component or individual files of a component, particularly if the source of the repair files294,296and298organizes software in a format different than that used by component repair service222to identify a corrupt component. For example, external server280may store groups of files in packages. Also, there may be software for multiple versions of the same component, corresponding to different versions of the OS being repaired or different versions of the component itself. Regardless of the specific organization of the software on the external server, an appropriate unit of software that can be downloaded may be identified by the mapping. In the illustrated example, that unit of software is a package. The unit of software could alternatively be an individual file or component.

Once a package292is determined, the package must be located on the external server280, which is accomplished in act506. The location may be represented by a Uniform Resource Locator (URL) or some other form of data that reflects the location within package storage290. Act308terminates at508once the location is determined.

If multiple files are to be obtained, the process ofFIG. 5may be repeated for each such file. The determined location or locations are then used as illustrated inFIG. 3. At act310, the component repair service222uses the determined location or locations of all the necessary repair files294,296and298to download the repair files, such as files294,296and298(FIG. 2). In some embodiments, the computer system210uses a network adapter212to communicate with the external server280, which also communicates through a network adapter282. Network adapters as known in the art may be used for this purpose. However, there are many ways that the computer system210can be connected to the external server280. It may be a direct connection, a Local Area Network, a Wide Area Network, the Internet, or an intranet. One of ordinary skill in the art would understand that any suitable connection may be used to connect the computer system210to the external server280. Further, it should be appreciated that files need not be obtained from an external server. The files could also be obtained from a peer to peer network source. The source also need not be limited to an external source. In some embodiments, a local store of repair files may be stored on the computer system210.

When the repair files294,296and298have been received by the computer system210in act310, the component repair service222can optionally validate the repair files294-298in act312. This validation process may rely on the same cryptographically secure hash function228and hash keys278used to detect corrupt components in act304. However, it is possible to use a validation process independent of hash function228, and any suitable validation technique may be used, such as a certificate or signature accompanying the repair files. Moreover, different validation techniques may be used for different files or different types of files. For example, a manifest276may be validated differently than a payload file274.

If the validation act uses the same hash function228, then the process is very similar to that shown inFIG. 6. Each received file is hashed by hash function228and the resulting value is compared to the stored hash key278. If the value returned by the hash function228matches the hash key278, then the repair file298is presumed valid.

The final act314of the process illustrated inFIG. 3is to repair the corrupt component. In some embodiments, this can be achieved by overwriting the corrupt files274by deleting the corrupt files274and replacing them with the repair files298. More complicated repair processes are also possible, such as selecting particular information from the repair file298to repair a specific part of the corrupt file274. Regardless of the specific repair process used, it may be performed for every file that has been determined to need repair in act308. Though, in some embodiments, different types of files or types of errors may be identified and may be accorded different repair priorities such that not all corrupt files must be repaired at one time. Once all the files requiring repair have been repaired in act314, the component repair service222software stops executing at act316.

The embodiments as described identify and repair individual corrupt files associated with a corrupt component. While such an approach may allow a repair to be performed quickly while consuming a relatively small amount of network bandwidth, it is not a requirement that components be repaired at the file level. Any suitable unit of software may be identified as corrupt and repaired. In some embodiments, only the smallest piece needed for repair is downloaded. The smallest unit available to download can be any size unit of the overall software environment being repaired. The smallest unit being downloaded may be the entire component, an individual file, or even a portion of a file that needs repair. In some embodiments, the entire file may not need to be downloaded, but instead just a portion of a file is downloaded.

Further, the embodiments describe an operating system being repaired. It should be recognized that any software, including applications, may be updated using techniques as described herein.

In a further embodiment of the invention, the component repair service222can be used in conjunction with a software updating service224to provide seamless software updates with minimal user interaction. An embodiment of this method is shown inFIG. 4. The software updating service224can start402in any suitable way. For example, it may start automatically, based on a timed schedule or when updates become available, or it can be manually initiated by a user101of the computer system210.

The software updating service224then receives a request to update certain software at act404. The request may come from a user101, from the OS134, from an application program135, from other program modules136or possibly from an external source, such as an external update server that provides information about available updates. The software updating service224determines which components to update at act406. The request to update software may specify specific components270that should be updated. It may, alternatively, have a set of rules to determine which software to update. For example, the request could indicate that updates should be performed on all components that have not been updated recently. In a further embodiment, the software update service224may check for updates on all components of the computer system210and update the components that have updates available. Accordingly, the specific event that triggers an update and the specific components updated are not critical to the invention.

Once the components to update have been determined in act406, the software updating service224will select one of the components270and repair the corrupt files in act300. This act may be the same as the component repair service222process that was described in detail in conjunction withFIG. 3. This process may be performed by the component repair service222. If the component that is being updated is corrupt, it must first be repaired by the component repair service222.

After being repaired, the component270is no longer corrupt and the component270may be uninstalled properly at act412. Uninstalling the component may include updating the registry230, changing and/or deleting files272-276associated with the component and other administrative tasks. At act414, the updated version of the component is downloaded from an external server280. These components may be part of packages291located in a package storage unit290. The updated component is then installed at act416.

If there are more components requiring updating, as determined at act418, then the software updating service224will return to act408, select the next component to update and repeat the updating procedure for each remaining component. The software updating service222is terminated at act420once all of the components determined to need updating have been updated.

Note that the order of the acts inFIG. 4is not limited to the order presented therein. For example, downloading the updated component in act414could occur at any previous point in the process. Furthermore, acts in the process may be performed simultaneously. For example, the downloading of the components in act414could occur while the corrupt components are being repaired in act300. Also, each component does not have to be updated in its entirety before moving on to the next component. Instead, all of the acts could be performed simultaneously for every component that is being updated by the software updating service224.

In yet another embodiment, repairs to corrupt files can cascade. For example, if the metadata file276is corrupt, then it cannot be relied on to supply a valid hash key278in order to detect corruption in payload file274. Therefore, the metadata file276must be repaired first. Once it is repaired, then the component repair service222can use the hash key278to check the payload274for corruption and complete the repair process for payload274.

In the previously discussed embodiments, the components240,250,260and270of an OS that is presently being executed are being repaired. In such an embodiment, access to any component that is being repaired or updated may be blocked. Any component to which access can be temporarily blocked may thus be updated, even while the OS is in use. However, in an alternative embodiment, an executing OS may repair components of images of a separate OS that is not currently being executed by a computer system. This may be achieved by allowing a currently executing OS to use its component repair service on files in an OS image that is stored in storage device210or some other external or removable storage medium.

In this respect, the invention may be embodied as a computer readable medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy discs, compact discs (CD), optical discs, digital video disks (DVD), magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other non-transitory, tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The computer readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above. As used herein, the term “non-transitory computer-readable storage medium” encompasses only a computer-readable medium that can be considered to be a manufacture (i.e., article of manufacture) or a machine.