Is it possible to dump a running program's memory (Windows OS), and then later "reinsert" that memory when the program is run again?

1 Answer 1


Actually, I think this should technically be possible, without having put too much thought into it. Freeze all threads, save thread context state for all of them, enumerate all of the memory used by the program and dump it alongside meta data.

A problem would be stuff like open handles (files, connected sockets etc.) but for programs within a limited scope I'd say it's doable. I don't know of any tool that implements something like that though.

On a bigger scale, snapshots in VM applications do just that.

Is there a specific case you'd like to solve with this?

  • Thanks. How about the reinserting part the next time the program is run, is that feasible? I'm not versed enough in this, but I wonder if it'd be difficult to reinsert if the OS dynamically maps memory for an application at run-time, and if it's not a continuous range of bytes/addresses. I'm envisioning a file fragmented across a HDD platter, and how it'd be possible to reinsert back into those frag locations, especially when the next time the program is run, the OS will have a different map of scattered fragments that the program's memory is laid out across. But maybe this isn't how it works. Nov 23, 2019 at 23:44
  • As for cases: 1.) snapshotting a program so it could be restored manually after a system reboot (without having to save the entire OS state like a VM does), and 2.) when reversing/debugging and a program, having the ability to quickly and easily restore the program to a certain point in time, since you can't normally unwind a program's instruction/execution path/jumps. So rather than having to restart the program and run it to a certain point again -- this time taking the jmp less traveled (so to speak) -- you could instead instantly restore the program's state to the point in time of that jmp Nov 23, 2019 at 23:52
  • ...but this time, taking the other (or another) jump and tracing down that path, or taking other alternative tests/flags/jumps/executions, without having to manually maneuver the program to get to that point and state of execution again (and potentially with different uncontrollable variables by that point, for any dynamic or generated variables that the user can't manually control or know of). Nov 23, 2019 at 23:54
  • Assuming your question is whether you can save state of a process by itself and then restore it at any time later, even after a restart, then the answer is not really. While you can restore the process virtual memory and CPU state, anything that relies on OS initialized data will lead to unpredictable behavior at best. Every single opaque handle (i.e process, thread, mutex) will no longer be recognized by the OS, all OS user modules will have been initialized from the previous boot, etc. Nov 24, 2019 at 2:41
  • As for using it in a debugger to add support for snapshots, it's much more possible, but depending on the circumstances may be faster to just use scripting. In this case the OS won't reboot so you don't have to worry about how the process was initialized itself, among other things, but you will still have issues with any kernel objects. Imagine you CloseHandle and then restore state to a WriteProcessMemory instruction, as far as the OS is concerned that handle will still be invalid so the behavior will be different than expected. Nov 24, 2019 at 2:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.