Take the 2-minute tour ×

I was under the impression that when a computer has crashed, something went wrong and it can't perform anymore.

I was wondering how is the computer able to save things before it crashes?

Is the computer really capable of knowing when it's going to crash (and thus inform all processes: "Save ASAP because I'm about to crash") ?

If not, how is it possible that programs like Chrome and Microsoft Word can offer "restoring" services after the computer has crashed?

share|improve this question
I like how the answer to the question is in the title of the question. –  Chris Jan 17 '12 at 15:08
How are emergency lights able to light up when the power is off? –  JoelFan Jan 17 '12 at 18:25
@JoelFan they don't if your battery/generator is dead =P –  Mechaflash Jan 24 '12 at 14:48
add comment

15 Answers

up vote 4 down vote accepted

When a computer "crashes", it may, eg, be due to an "abrupt" power failure (in which case nothing can be done), it may be due to some sort of nasty internal event (eg, corrupted page tables) that similarly prevents doing anything, or it may be due to some condition that simply prevents "further operations" somehow -- perhaps new processes cannot be started, perhaps the display cannot be updated, perhaps the system has simply run out of storage.

In these latter situations the OS can still function, within limits, and can at least complete disk operations that were ongoing, nicely close files, etc. In addition, if slightly more function is possible, the OS may be able to tell the various application processes to shut themselves down cleanly.

But even if the system goes down "hard", the system as a whole and individual applications may have maintained a system of "journals" and/or "checkpoints" to allow the state of the system as a whole and individual applications to be restored to an "atomic" point, where everything is "internally consistent", and where a minimum of important data has been lost.

This all isn't accomplished with a single mechanism, but with layers of functionality at the system and application level.

With regard to power failures specifically, there may or may not be advance notification, and the "advance" warning may be a fraction of a second or (with UPS or a failing laptop battery) several minutes. What can be done depends on the amount of warning.

In most cases, with a desktop sysyem without UPS, there is at best time to "quiesce" disk operations so that no disk is in the middle of a write when power finally disappears. This prevents generating bad sectors on disk. It used to be, when RAM was much smaller, that there could be enough time (with large capacitors in the power supply, or even, oddly using the energy stored in the disk drive rotor to generate electricity) to write RAM to disk before power dropped, but that possibility pretty much vanished when RAM grew larger than 100M or so.

[And note that, in the olden days, when memories were made with magnetic "cores", RAM was inherently preserved when power was lost (though a particular word being read/written when power failed might be corrupted). This made it easier for those old systems to recover from power failure.]

However, with something resembling a UPS (which may give anywhere from a few minutes to several hours of additional power) there are several more options. One is to simply shut the system down, as if you requested "power off". This causes each application to end itself, and then the system as a whole writes out permanent tables and shuts down. This can take a long time (as I'm sure many of you have noticed). But it's also possible to use a "hibernate" strategy, where RAM is written to disk as a single block, and then the system powered off. In the "hibernate" scenario, on restoring power, the RAM is read back in to exactly where it was written from, a few bits here and there are swizzled, and then execution resumes where it left off.

On some older "big iron" systems a semi-hibernate strategy was used to do an emergency shutdown: Memory would be written out as above, but when power was restored and memory read in then a standard shutdown would occur. This was done because some bits of system state (particularly in I/O controllers) could not be reliably saved/restored to permit continued operation.

share|improve this answer
add comment

Chrome and Microsoft Word periodically save your current state as you're working. If the application or computer crashes, when the applications relaunch, they look for a saved state on disk, and restore it for you. They don't need to predict the crash; they are constantly saving your state in case something goes wrong.

share|improve this answer
This is only partially true. The OSes now provide frameworks to help applications recover from exceptions. –  surfasb Jan 15 '12 at 23:06
@surfasb: Could you be more specific? We've always been able to catch signals in Unix-like systems, but it's up to the application programmer to do anything about it. –  Dietrich Epp Jan 16 '12 at 2:09
This answer is correct. Most applications with error recovery save their data periodically. The OS can't know when it's about to crash. And when it finds out, it's too late. –  Bogdacutu Jan 16 '12 at 12:40
@surfasb, the question asked about the computer ( Kernel presumably ) crashing, not the application getting an exception, which generally is either handled and everything is fine, or at best, the process core dumps, not saves your documents. –  psusi Jan 17 '12 at 4:39
add comment

EDIT: This only works when an application crashes, not Windows.

Since Windows Vista there is a new API that allows Windows to call a special function in the application when it crashes so it can try to recover any data before it is shut down. It works like this:

  • App starts up
  • App calls Windows function: when I crash please execute RecoverData()
  • ...
  • App crashes
  • Windows executes RecoverData() in the App
  • RecoverData() tries to retrieve data about the currently opened document, in the mean time it keeps pinging Windows to tell it's still busy recovering.
  • When RecoverData() has finished/times out/stops pinging, Windows terminates the App and restarts it.

More info: http://msdn.microsoft.com/en-us/library/windows/desktop/aa373351(v=VS.85).aspx

share|improve this answer
+1: This is one of the most underused tools out there sadly. And also sadly, this isn't the most upvoted answer?? –  surfasb Jan 15 '12 at 23:07
+1 for developer information –  Mzn Jan 15 '12 at 23:35
@ZippyV however, isn't it true that if it's not hte app that crash but windows itself that crashes, the computer do not have the capability to call RecoverData()? –  Pacerier Jan 16 '12 at 3:11
The OP is asking about the computer (OS) crash, not the application crash, therefore this answer is irrelevant. –  vitaut Jan 16 '12 at 7:54
True, in the case of a BSOD, this will not work. –  ZippyV Jan 16 '12 at 8:27
show 3 more comments

Well, they just save the current state before they crash. Like an auto save every X seconds.

I think one really has to differentiate:

  • Hardware crash: Only able to recover with previous checkpoints
  • OS Crash: no way for app to save data, OS can drop something like a core dump
  • Application crash: OS features for application crash can save information
share|improve this answer
Yes I was talking about the more serious crashes like OS/hardware crashes –  Pacerier Jan 16 '12 at 23:04
add comment

It depends on the severity of the crash. A very severe crash (at the lowest level of the computer) will cause the computer to simply halt. The only work that is saved is by each application auto-saving their data periodically.

For less severe crashes, the computer will warn each program that it needs to shutdown. IF the program listens to this message, this is where the program will save the current data. However, not all programs pay attention this message.

share|improve this answer
I don't think the latter part actually possible though. Windows only give you a BSoD if it detects an exception in kernel mode or other fatal error that means some data in the kernel address space is corrupt. Because kernel mode programs (drivers, etc) have unlimited memory access, the error cannot be easily isolated to components so the whole system must be shutdown in kernel mode. Signaling user space programs to save data essentially means resuming much of the functionality of the kernel which is very dangerous. –  billc.cn Jan 15 '12 at 23:06
The latter part seems to refer to userspace crashes, not BSoDs. –  3Doubloons Jan 16 '12 at 5:24
add comment

The programs save they state periodically in a file on disk. The computer isn’t capable of knowing it. In fact, the crash dump isn’t even performed using the disk driver — the system simply pages all memory out.

share|improve this answer
Paging is done with the disk driver -- without it the kernel wouldn't know how to write to the disk. –  psusi Jan 17 '12 at 4:46
@psusi When the system crashes, the pagefile is the only place kernel knows it can safely write to. –  kinokijuf Jan 17 '12 at 13:15
Yes, and it actually does the writing via the disk driver. –  psusi Jan 17 '12 at 18:16
No. It does via a special "dump_atapi.sys" (substitute atapi for your SCSI controller) driver, NOT the standard disk driver. I think it even uses Int 13h. –  kinokijuf Jan 17 '12 at 18:18
add comment


Yes, this is completely true. However, from a logical perspective, your program isn't running unrestricted on the computer. The program is running under the operating system!

I was wondering how is the computer able to save things before it crashes? Is the computer really capable of knowing when it's going to crash (and thus inform all processes: "Save ASAP because I'm about to crash") ?

Well, in the case of a BSOD or kernel panic, the operating system determined that a really unsafe thing was going to happen (invalid memory pointer, overwrite of some memory allocated to the OS kernel, access to non-existent hardware, etc...). In that case, the operating system calls for all processes to halt execution, saves the contents of the RAM to disk (since the OS is also responsible for managing the memory allocation), and safely shuts down or restarts the computer.

Individual applications themselves crash when there is an unhandled exception thrown by the program, which propagates into the operating system. In this case, the OS will stop execution of the program, and close any open memory/file handles.

In both of the above cases, program execution is not usually terminated gracefully. In these cases, it's up to the individual applications to recover their own data, since they suddenly just "stop" executing.


IIRC, both of those applications periodically save the application states to disk to prevent data loss if the aforementioned condition occurs. For example, Word auto-saves a backup copy of your current working document every few minutes so that in the event of a sudden hard-reboot, you can still recover your data (give or take a few minutes of work) without you having to have done anything.

Again though, as a developer, it's your own responsibility to ensure that your application can deal with these situations.

share|improve this answer
"In that case, the operating system calls for all processes to halt execution, saves the contents of the RAM to disk, and safely shuts down or restarts the computer." - the RAM contents which are saved to disk, when do they get "restored" ? –  Pacerier Jan 16 '12 at 23:10
They don't in the normal course of events. However, if your computer is regularly crashing, a skilled programmer may be able to use this file to figure out the cause. –  kindall Jan 17 '12 at 0:53
@Pacerier as kindall stated, they don't get restored (since if you did restore the RAM, you would be in the same execution state which caused the computer to crash in the first place!). You can change what is written to disk in Windows under System Properties -> Advanced -> Startup & Recovery. And again as kindall stated, this information is mostly useful to developers trying to determine what caused the error. –  Breakthrough Jan 17 '12 at 15:13
add comment

yeah, the data restore process is not just for computer crashes, it is for power outages, program crashes, quitting without saving, and much more..

What you said is true, the computer can't 'know' when it is going to crash, in the case of Word, it periodically autosaves so that it can restore that data. In the case of Chrome, it probably stores the info for every tab somewhere and deletes it on a successful quit, or when a new and different session begins.. or probably other ways too.. anyway, that way, if it didn't end with a successful quit, it has that data to restore to.

I (obviously) don't work for Microsoft or Google, but that is probably the way (or close to the way) it works.

share|improve this answer
add comment

A program can write a flag to the disk that just says something like "On bootup, if this flag is set then something went wrong". On bootup that flag is checked to see if it's set. If it is, the program knows something went wrong.

The flag always works, because it can be set as soon as the program starts up, and turned off when the program exits normally. If the program exits do to an unexpected error, like a computer being powered off unexpectedly, the flag will still be set since it didn't exit normally. Then the program is able to tell that it didn't exit normally the last time it was run.

share|improve this answer
add comment

Like @bamboom says, there are several different types of computer "crashes" that have to be handled differently. Effectively a power outage is very different from, say, an integer division by zero error.

With many programming languages also supporting exceptions (controlled branching to an error handler when something goes completely wrong), there is the possibility of having a top-level application-wide error handler which can save the application's state (including any open documents, changes made, etc.) when an unhandled application error occurs. The idea then is to try to read it all back when the application is restarted. Depending on the type of error and exactly how this is implemented, it doesn't always work, and of course it's up to each separate application to do something meaningful in the face of an error and with the resulting data - but it can be a surprisingly effective strategy at helping the user recover from a crash with a minimal amount of lost work.

share|improve this answer
add comment

I would like to a low-level point here, as there is a tag of filesystem.

You could have remembered Windows OS which used FAT/FAT16/FAT32 file system. There sometimes were problems when a user experienced a power outage and the whole system went down. After trying to reboot it would say that a file was missing and it is not possible to boot. This happened because FAT32 didn't keep track of the operations it was performing in a transactional manner.

In contrast newer NTFS file system received journal support of its infrastructure, which means on the low level of OS and hardware access layer information would be kept in a stable safe condition by recording of any actions to be commited.

share|improve this answer
add comment

In some applications on some operating systems, it is possible to hook into signals such as segmentation faults indicating memory access violations. In this case, a simple routine can save as much data as possible. Whether or not that data is usable is another question - the crash may have corrupted it. Whilst it is possible for an application to continue running after it interrupts a signal, it's not recommended, as it may be in an unstable state with corrupt memory that may cause further problems.

Other applications use auto save, or a combination of both - it depends on the needs of the program and platform support for catching these signals.

share|improve this answer
Hint: Windows does not have them. –  kinokijuf Jan 17 '12 at 18:37
add comment

A system crash is just another routine that is run by the OS. The reason a "Crash" happens is because a program or library failed to load or did not load properly and has the ability to cause permanent harm to system files. So as a safety precaution, windows forces a shutdown/restart and stops all writing to system files before any these files are allowed to be edited by the delinquent program/library.

Prior to shutting down/restarting, it performs the same functions as a regular shutdown/restart: i.e. saving system files etc.

As far as single applications (Word/Chrome) saving your "Progress", that's an internal function of the application, saving your progress at specific intervals (which you can usually change in the program settings as well). If you have a application/system crash, after reboot, it can look at that file and ask you if you wish to restore the session.

share|improve this answer
add comment

You may be talking about the OS shutting down due to loss of power. This arguably is a kind of crash.

The power supply informs the mainboard (through a signalling wire, I suppose) about any long interruption of its input, the proper wall AC current, well in advance of it stopping its output, which is the proper supply of DC current to the mainboard. It can do this because it stores its electricity in large capacitors. The OS receives this signal in the form of a hardware interrupt.

During this long interval, there is enough time for a write-buffering filesystem to transfer all the buffered writes to the permanent physical storage medium, as well to perform some other shutdown routines.

One big advantage of a write-buffering filesystem is that by sorting writes, it can reduce arm movements on hard disk drives, making them fewer and less distant.

This is similar to what @oleksii says in his answer, except that in a write-buffering filesystem, completed transactions are not normally immediately transferred, but merely buffered. On power failure, completed transactions should be transferred to disk.

share|improve this answer
add comment

Apps can catch signals in C and save certain data. One signal you may get accidentally is SIGFPE Floating-Point arithmetic Exception (ANSI). Errors include division by zero and overflow. Another singal is SIGINT which is raised by pressing ctrl+C on the console or terminal which kills the app

share|improve this answer
add comment

Your Answer


