Modern commercial computer software has increasingly become more user friendly. The increased ease of use has often required software of increased complexity. A software manufacturer typically makes substantial efforts to eliminate errors from its software before the software is placed on the market. After a program has been marketed, software manufacturers continue their efforts to locate and correct possible software errors. However, modern applications can represent the compilation of millions of source code lines. Despite the manufacturer's best efforts, errors can remain in software prompting unintended results.
Users of a given piece of commercially available software can number in the hundreds of thousands. With such a large customer base, it can be more difficult for the manufacturer to detect software-related errors that affect a small portion of a user population. Even if such errors are anecdotally reported to the manufacturer, it may be difficult to quickly identify a pattern and provide a possible solution.
To assist software developers in better identifying potential errors, other commercially available software has been developed to collect information upon the occurrence of a program error. One such software is the MICROSOFT WATSON product, which creates a snapshot of a portion of the computer's memory at the time of a crash. The crash is an event that is usually prompted by an error. It prevents the further normal operation of the software and, depending upon the severity of the error, of the computer system itself. Users may be offered an opportunity to transmit the crash data to a given location to provide the manufacturer an opportunity to diagnose the cause of the error.
The crash data can contain information to assist in identifying program errors. However, users ultimately want prompt solutions. The present approaches do not always provide sufficient information to enable a manufacturer to promptly diagnose and address application errors. Specifically, it may be difficult to locate certain software errors unless the application executing at the time of the crash can be adequately identified. For example, installation of a new application on a personal computer often begins by executing a program named “setup.exe.” The content of the setup.exe files differs for each application being installed even though the file name “setup.exe” is the same. Thus, if an error occurs during the execution of setup.exe, merely knowing that the setup.exe file produced an error is insufficient to identify the specific application being installed.
In various instances when the application can be sufficiently identified, necessary information concerning the computing environment in which the application was executing at the time of the crash or other error is often unavailable. For example, an operating system upgrade may create incompatibilities between the operating system and a given application. Without knowing the operating system and other computer environment information, a diagnosis of the problem can be more difficult. Similarly, applications often rely on multiple Dynamic Link Library, or DLL, files to provide certain functionality. An application may trigger an error because one of the pertinent DLL files contains errors or has become incompatible with the operating environment. For example, a user may have installed unrelated new software that, unbeknownst to the user, installed a new or outdated version of a DLL file in place of a current version. Thus, the application itself may not require modification because the error was in fact caused by a faulty or outdated DLL file. Without information identifying the application and its computing environment, it can be difficult to accurately diagnose and address errors. Moreover, even if the error could be preliminarily identified, there is no satisfactory method for quickly locating an existing, relevant response for the user.
USPTO Backgrounds
USPTO Backgrounds