hi there...
please provide me some genuine reasons for system crashing at regular intervals. similarly is there any simple way of avoiding it or escape from such crashes.........
please give some suggestion..........
hi there...
please provide me some genuine reasons for system crashing at regular intervals. similarly is there any simple way of avoiding it or escape from such crashes.........
please give some suggestion..........
First step for you to follow is to download the software HijackThis (HJT).
Download and Save HJTsetup.exe and by double clicking install it in your pc.
Continue clicking the window as they come during the installation process.
As the installation finishes, run the software and continue to follow the rest of the instruction given by that software.
Click on the option in the software do a system scan and then click to save a log file button. It will thus scan and then will ask you to whether save the log file.
Save the log file and then try to open the log file in notepad.
Then go inside Edit option in the notepad and then Select All as an option
Also Then click on Edit and then Copy in order to copy the complete contents of the log.
Roll back at this particular site from where you downloaded it and then try to paste the log file in your next reply.
As you post the log file, you have to wait for a certainly responsible person as he will explain in his reply of what perform next in your computer to solve your problem.
A crash or (system crash) in computing is a condition where a program (either an application or part of the operating system) stops performing its expected function and also stops responding to other parts of the system. Often the offending program may simply appear to freeze. If this program is a critical part of the operating system kernel the entire computer may crash.
Many crashes are the result of the execution of a single machine instruction, but the causes of this are manifold. Typical causes are when the program counter is set to an incorrect address or a buffer overflow overwrites a portion of program code due to an earlier bug. In either case, it is quite common for the processor to attempt to execute data or random memory values. Since all data values are possible but only some values are valid instructions, this often results in an illegal instruction exception. By chance such data or random values could be valid (though unplanned) instructions. If while successfully executing such instructions the processor happens onto a branch instruction that moves the program counter back a few bytes it would simply repeat those few instructions over and over, being stuck in an endless loop. One might say that the original bug that upset the program counter "caused" the crash, but the actual fault was an illegal instruction or endless loop some time later. The art of debugging such crashes is connecting the actual cause of the crash (easily determined) with the code that set off the chain of events. This is often very far from obvious—the original bug is usually perfectly valid code from the processor's perspective.
On earlier personal computers, it was actually possible to cause hardware damage through trying to write to hardware addresses outside of the system's main memory. Occasionally, execution of arbitrary data on a system will result in a breakup of screen display. This is widely considered a severe system crash.
Another cause of crashes is a race condition in communication between processes. One process may send a signal to a second process then stop execution until it receives a response. If the second process is busy the signal will be forced to wait until the process can get to it. However, if the second process was busy sending a signal to the first process then both processes would wait forever for the other to respond to signals and never see the other’s signal. If the processes are uninterruptible they will hang and have to be shut down. If at least one of the processes is a critical kernel process the whole system may crash and have to be restarted
An application typically crashes when it performs an operation which is not allowed by the operating system. The operating system then shuts down the application.
Typical errors that result in application crashes include:
attempting to read or write memory that is not allocated for reading or writing by that application (general protection fault)
attempting to execute privileged or invalid instructions
unforeseen circumstances or poor code writing that results in the program executing an endless loop
attempting to perform I/O operations on hardware devices to which it does not have permission to access
passing invalid arguments to system calls
attempting to access other system resources to which the application does not have permission to access (bus error)
A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer software. A segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (for example, attempting to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as address or bus errors.
Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.
On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception, and usually a window asking the user to send an error report to Microsoft appears.
Bookmarks