Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a tool that would enable me to identify which blocks of data were last (most recently) written to an NTFS volume? Perhaps the NTFS volume's "$Journal" file might have information that can be extracted or analyzed / interpreted. Is there a tool that will identify which clusters or sectors were last written to or changed on an NTFS or FAT volume?

I ask becuase the computer I was using died (quickly, without any blue screen -- I assume no memory dump was made by Windows) when a 2-4 or so MB file was being saved to the internal hard disc. I wonder if any of the contents of that file actually did get physically written to the hard disk. It's possible that any contents of the file that were to be written physically were still only in the ram i/o buffer. If this is the case I don't think I will be able to retrieve/find any (even portions) of the data belonging to that file (unless *). However, I am wondering if it is possible that the partial contents of that file did indeed get written to permanent storage. I was running Windows 7 64 bit and writing to the C: volume (the main, system NTFS volume on that h.d.d.). The motherboard (and/or power supply) have been flaky for some time. It's crashed on me like this before.

I have started to learn about The Sleuth Kit. It's an open-source, free Forensic software suite that can be installed in any GNU/Linux distro (or other UNIX-like systems, as well, I believe). Perhpas one of the apps that are part of that suite of tools could be used for this purpose. one such app in TheSleutKit is blkls. Running it in default mode, without any switches will output the raw (binary?) contents of all unallocated blocks/sectors on the storage device/partition to stdout (1>>) (or | ). However, I don't think that will be helpful since this is the NTFS system volume and many of those unallocated blocks contain deleted files that are older than the one file that I am looking for fragments of. If all of those unallocated blocks never before contained any data, perhaps blkls would be helpful for this purpose.

Speaking of the possibility of a RAM dump, I recently read that, when Windows creates a memory dump, the contents of (Some or all) (perhaps only select process(es), if not an entire image of the RAM) RAM are copied to the hibfil.sys and then, upon next boot of Windows, that memory dump is extracted and saved to a seperate .dmp file somewhere in C:\Windows or the user folder. Is it possible that if any of the data that was going to be written to the NTFS volume was first in a RAM I/O buffer, that any of that would be part of a memory dump?

share|improve this question
Is there a lot of free space on the drive in question? If not, then just dump all unallocated clusters and check. If there are your luck may depend on the file type. Is it a standard type? If so, then try data-recovery programs like PhotoRec. – Synetech Mar 10 '12 at 21:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.