207 results about "Software failure" patented technology

The present invention provides a flexible and extensible execution control system for distributed computer systems including multiple nodes interconnected through a network. Distributed computer systems that include an execution control system consistent with the present invention can be used for more types of applications than systems using prior art. The applications running on a distributed computer system that includes an execution control system consistent with the present invention can achieve better protection from hardware and software failures than systems using prior art systems and methods.

In accordance with the present invention, computer implemented methods and systems are provided that allow an application to automatically recover from software failures and attacks. Using one or more sensors, failures may be detected in the application. In response to detecting the failure, the portion of the application's code that caused the failure is isolated. Using the input vectors that caused the failure, information regarding the failure (e.g., the type of failure), a core dump file (e.g., stack trace), etc., an emulator-based vaccine that repairs the failure is constructed. In response to verifying that the vaccine repaired the failure, the application is automatically updated with the emulator-based vaccine without user intervention. Application community features that efficiently use the resources available in software monoculture is also provided. An application community may be defined that includes a plurality of devices and the application's code may be divided into smaller portions of code, which are assigned to each of the plurality of devices for monitoring. Each device also notifies the other devices of the failure.

Volatile memory is placed into a data-preserving safe state in a computer system in response to any one of a reduction in power applied to the volatile memory, a bus reset signal on a data communication bus of the computer system, and an absence of a bus clock signal on the bus. The volatile memory is powered from an auxiliary uninterruptible power supply in response to the reduction in power. The volatile memory is also placed into the data-preserving safe state in response to a cessation in executing software instructions by a CPU of the computer system. Placing the volatile memory into the safe state in response to and under these conditions enhances the opportunity to preserve data in response to error and malfunction conditions.

User input defines transmission filter rules to be met when sending an error report to a support provider. User input also defines collection filter rules to be met when including failure data within an error report. Error reports corresponding to crash failures at clients are filtered with the transmission filter rules to determine which of the error reports to send to the support provider, and each error report to be sent to the support provider is further filtered to remove any failure data that fails to satisfy the collection filter rules. Each error report that satisfies the transmission filter rules, along with the failure data satisfying the collection filter rules, is sent to the support provider for analysis. Standard and or custom failure responses corresponding to the failures at the clients may be retrieved and sent to the clients in accordance with the collection filter rules.

Methods and arrangements are provided that substantially reduce the requisite amount of data required to conduct postmortem analysis following a computer failure. The methods and arrangements can be advantageously configured to allow for rapid online user support for a variety of users, computing devices, operating systems, applications, and the like. One method includes determining when to generate a dump file, and generating a dump file by gathering thread, callstack and thread context information for the running thread, process identifying information associated with the running thread, and information identifying the reason for generating the dump file. The resulting dump file is then stored to a storage medium and accessed during subsequent analysis. The dump file can be a kernel minidump file that is associated with an operating system program failure, in which case the running thread is the single thread that was running when the failure occurred. The kernel minidump file would include the kernel callstack and the process identifying information that would identify the process that initiated the single thread. The method is further applicable to non-operating system programs, wherein a user minidump file is generated by also gathering callstack information for all running threads, thread context information for all running threads, and a listing of all loaded modules for the faulting non-operating system program.

A failsafe mechanism for installing and removing temporary instrumentation during a runtime of an application. Initially, an application is configured with a baseline set of instrumented components such as methods. Additional instrumentation is then deployed in the application, such as to diagnose a performance problem. The failsafe mechanism ensures that the additional instrumentation is automatically removed, even when there is an interruption in a communication link to the application, a computing device failure, a software failure, or some other type of failure, which renders it impossible to manually roll back the instrumentation from a remote user interface. The failsafe mechanism can be provided using callbacks between the computing devices which detect when a connection is unexpectedly lost or closed. Termination of one callback can cascade to one or more other callbacks. The instrumentation rollback can involve reloading un-instrumented byte code of the application.

Improved methods for providing recoverable workflow of complex and/or risk-prone workflows in a computer system or computer network include segmenting such workflows into sub-processes, associating a checkpoint with the end of each sub-process, and determining whether processing of each sub-process was successful. If so, a set of parameters is stored at each checkpoint before processing the next sub-process, but otherwise processing of the failed sub-process is retried, using the parameter set stored at the previous checkpoint. In one embodiment, the methods are implemented by a certified messaging capability that guarantees delivery of any message. In the event a hardware or software failure occurs during a sub-process execution, the certified messaging capability returns a failure indication, so that execution of the failed sub-process can be reinitiated. Improved computers and computer networks for providing recoverable workflow are also described.

The invention discloses automatic analysis method and device of the crash information of computer software. The method comprises the following steps of: (A) analyzing a dump file and outputting an analysis result; (B) parsing the output analysis result to acquire crash information; and (C) sorting the parsed dump file and storing a sorted result. The invention also discloses the automatic analysis device of the crash information of the computer software. In the invention, the crash dump file is analyzed by automatically calling a debugger provided by a toolkit of Debugging Tools for Windows to acquire the comprehensive and accurate crash information; and the crash information is sorted by using a crash address and a crash stack, therefore, not only the sorting accuracy is improved, but also the redundant information stored in a table is greatly reduced. By applying the invention, calculation staff in the field can accurately acquire the crush reason and provides reference for solving the software failures and optimizing the software.

A system and method provides for failover of guest operating systems in a virtual machine environment. During initialization of a computer executing a virtual machine operating system, a first guest operating system allocates a first memory region within a first domain and notifies a second guest operating system operating in a second domain of the allocated first memory region. Similarly, the second guest operating system allocates a second region of memory within the second domain and notifies the first operating system of the allocated second memory region. In the event of a software failure affecting one of the guest operating systems, the surviving guest operating system assumes the identity of the failed operating system and utilizes data stored within the shared memory region to replay to storage devices to render them consistent.

A method and system for debugging a computer upon a kernel hang and/or upon a software failure, the method comprising executing a debugger on a remote computer, connecting the hung or crashed computer to the remote computer with a communications link, and debugging the hung or crashed computer with the debugger without rebooting the system. The method may include deconfiguring any kernel driver of the computer attached to the communication card prior to connecting the remote debugger to the computer.

Disclosed herein are a robot capable of recovering from a failure of one of a plurality of symmetrically structured modules, and a recovery method thereof. When a hardware or software failure occurs, the robot recovers by itself by replacing the failed module with another corresponding module. Accordingly, resources of the robot can be more efficiently utilized.

The invention provides a reliability evaluation system design method based on software fault injection. In the method, a computer system is tested and evaluated specific to reliability serving as an important index for evaluating the performance of the computer system, and the fault-tolerance performance of a fault-tolerance system is tested and estimated by means of fault injection which can contribute to accelerating system failure. The invention introduces a design method of a fault injector oriented to reliability evaluation of the fault-tolerance system on the basis of the thought of software fault injection, and the method has the advantages of diverse fault types and triggering ways, realization of injection faults similar to real faults, easiness in operating, small influence on the system and the like, and can be used for effectively evaluating the system reliability.

The invention relates to a fully-digital relay protection reliability system based on software failure and human failure, and an evaluation method of the system, and belongs to the field of relay protection reliability of power systems. The fully-digital relay protection reliability system comprises a hardware reliability system, a software reliability system and a human reliability system, and when a failure occurs in any one of the hardware reliability system, the software reliability system and the human reliability system, the fully-digital relay protection reliability system fails to work. The evaluation method comprises the following steps: establishing the hardware reliability system, the software reliability system and the human reliability system for the fully-digital relay protection reliability system; establishing a Markov state space of the fully-digital relay protection reliability system; and calculating the availability of the fully-digital relay protection reliability system according to a Markov system. The sum of the probabilities of steady state of the fully-digital relay protection reliability system in the normal state is the system availability. By considering the software and human failures which influence the relay protection reliability, the relay protection reliability system capable of effectively simulating the condition of state transition of the fully-digital relay protection system, and the evaluation method are established, and the problem that the conventional system considers the hardware failure in protection only from a perspective of the protective device without considering other factors of protection reliability is solved.

The present invention discloses a software system failure diagnosis method. The method comprises: acquiring a failure attribute of a to-be-diagnosed software system by means of a network management system; and performing a match in a preset rule database according to the failure attribute, and generating a failure diagnosis decision list according to a matching degree of the failure attribute and the preset rule database. The present invention further discloses a software system failure diagnosis server and system. According to the software system failure diagnosis method, server and system disclosed by the present invention, intelligent diagnosis and repairing of software system failures, real-time software system failure monitoring and online update of diagnosis rules are achieved, the efficiency and automation degree of software failure diagnosis and repairing are greatly improved, and maintenance and improvement efficiency of the diagnosis system are improved, and thus the technical problems of high learning costs and inconvenience of the existing software system maintenance are solved.

The invention belongs to the field of trusted computing, and relates to an embedded software trusted attribute modeling and verification method. The method comprises the following steps that (1) a semi-formal model is built; (2) the semi-formal model is converted to a trusted embedded software model ZAM on a finite field, wherein the trusted embedded software model ZAM comprises a time model, a static model and a dynamic model; (3) a ZMTL timing sequence logic formula describing embedded software trusted attributes is given, and trusted attributes of the ZAM model are verified through an FZMCA algorithm. A trusted embedded software modeling and verification frame is divided into a UML/MARTE graphical layer, a model converting layer, a ZAM model layer and a model verification layer. Modeling and verifications can be conducted on the embedded software trusted attributes according to the method to reduce trusted attribute defects of embedded software in the developing process and reduce software failure probability.

A blocking device for preventing the actuation of an automatic depressurization system in a pressurized nuclear reactor system due to spurious signals resulting from a software failure. The blocking signal is removed when the coolant level within the core makeup tanks drop below a predetermined level.

A method and system for measuring a customer impacting failure rate in a communication network are disclosed. For example, the method collects a plurality of customer impacting network failure events, where the plurality of customer impacting network failure events comprises both hardware failure events and software failure events associated with a particular type of router or switch, or a particular type of component of the router or the switch. The method computes a Mean Time Between Outage (MTBO) metric from the plurality of customer impacting network failure events and compares the MTBO metric with a MTBO goal metric, wherein the MTBO goal metric is calculated in accordance with a predicted Mean Time Between Failure (MTBF) metric.

Improved methods for providing fault tolerance in a distributed computer system utilize an explicit, delayed acknowledgement message protocol to send an acknowledgement message to a workflow-requesting entity, such as a load manager and/or a requesting client, only upon completion of a workflow. The system includes workflow engines operating as a distributed queue group to load-balance processing requests from clients. The system also has a certified messaging capability that guarantees delivery of any message sent by a certified message sender by maintaining a persistent record of the message until an acknowledgement message is received back from the certified message receiver. In the event a hardware or software failure occurs during a workflow execution, the workflow is reassigned to a different workflow engine. Improved fault-tolerant computers and computer networks are also described.

The invention relates to a hardware acquisition system and a method for equipment failure log. A logic device is connected with a watchdog device and the JTAG interfaces of CPU, respectively and is used for receiving trigger from the watchdog device when overtime overflow occurs; boundary scanning is executed for a selected unit in CPU by the JTAG interface according to preset boundary scanning logic and the equipment failure log is generated according to the obtained boundary scan result; in addition, the CPU reset is triggered after the boundary scanning is completed. The hardware acquisition system and the method for equipment failure log is not limited by the software failure degree of the equipment and can still ensure the acquisition of key information even when the failure of the equipment software system is very serious.

A software sparing process and apparatus to reduce the likelihood of software failures is provided. Software sparing provides software entities, called spares, which take over and provide similar functionality as the failed system to the clients of the failed entity. They also permit the introduction of new software versions with no loss in service during the switch over period. These spare entities, which may be located on different nodes in a system, communicate using a standard interface protocol. Sparing is done at the software "chunk" level instead of at the hardware box level, which is the common practice, resulting in lower costs and improved reliability. A computer readable storage medium containing a program element to direct a processor of a computer to implement the software sparing process described earlier is also provided.

In order to prevent a user equipment, called UE hereinafter, from wasting unnecessary radio resources and occurrence of software failure of the UE, a method of performing an operating frequency transferring request for the UE in a wireless communications system includes reporting a request message to request for transferring to a preferred frequency corresponding to UE interested MBMS services when the UE operates in the CELL_DCH state and has successfully selected the preferred frequency as a current operating frequency.