SANS Digital Forensics and Incident Response Blog

OpenSaveMRU and LastVisitedMRU

Talking with a colleague the other day reminded me of just how nuanced many of the forensic artifacts are that we rely upon. Nowhere is this more true than in the Windows Registry. With no specification and even Microsoft products not following any data storage methodology, it is about as haphazard and irregular as they come. As an example, let's look at the OpenSaveMRU and LastVisitedMRU Registry keys. Both have been documented for years and are frequently cited in examinations. That being said, I would bet many examiners have not investigated the keys deeply enough to understand everything they are telling us. Here is a quick rundown on what we can glean from these keys.


In simplest terms, this key tracks files that have been opened or saved within a Windows shell dialog box. This happens to be a big data set, not only including web browsers like Internet Explorer and Firefox, but also a majority of commonly used applications. What sometimes gets missed is that this key is also responsible for tracking auto-complete terms for that same dialog box. We'll see why that matters in a moment.

OpenSave Dialog AutocompleteOpenSave Dialog Autocomplete Example

The key is located at HKCU&#092Software&#092Microsoft&#092Windows&#092CurrentVersion&#092Explorer&#092ComDIg32&#092OpenSaveMRU (OpenSavePidlMRU in Vista/Win7) and contains values and multiple subkeys. The values stored in the key itself are items that do not have file extensions associated with them. Since most files have extensions, what often ends up here is auto-complete information. Consider an OpenSave dialog box that allows you to choose your file type from a list (e.g. .jpg, .png, .bmp). User input into this dialog will typically be the name of the file without the extension, since the dropdown filetype menu takes care of that. Thus what is stored in the key is the auto-complete information for that transaction, and the full filename is not stored.

The possibility for a large number of subkeys exist within the OpenSaveMRU key. All but one of these correspond to various file extensions and store full path information for files of that extension that have been opened or saved. The one outlier is the * subkey. This key tracks the last ten files of any extension (including no extension) that have been input into the OpenSave dialog. Vista and Win7 appear to have extended the * subkey to track the last twenty files and are now using binary instead of string format. Each subkey keeps its own Most Recently Used (MRU) list and last write time.


This key is a little simpler, but often misunderstood. It is located at HKCU&#092Software&#092Microsoft&#092Windows&#092CurrentVersion&#092Explorer&#092ComDIg32&#092LastVisitedMRU (LastVisitedPidlMRU in Vista/Win7) and tracks the specific executable used by an application to open the files documented in the OpenSaveMRU key. In addition, each value also tracks the directory location for the last file that was accessed by that application. Data is stored in binary format. Ever wonder how an application remembers where you last opened a file from? This key is used by the OpenSave dialog box to show the last directory used by that application when you are attempting to open or save a file. It keeps its own MRU list and last write time.

LastVisitedMRU ValueLastVisitedMRU ValuePutting It All TogetherPutting It All Together

While checking my work via online resources, I was surprised at how little usable documentation exists. Kudos to Harlan Carvey for documenting a large number of registry keys, but weeding through thesis papers, forum posts, and Google Books results just isn't efficient for very specific, nuanced artifacts like these. What would really be ideal is a collaborative environment like a wiki. As luck would have it, our community already has a Forensics Wiki. After years of encouraging students to contribute, I am proud to say that I finally signed up for an editor account, and I am looking forward to collaborating on these keys (and others) there.

Chad Tilbury, GCFA, has spent over ten years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He teaches FOR408 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response for the SANS Institute. Find him on Twitter @chadtilbury or at


Posted April 2, 2010 at 8:56 PM | Permalink | Reply

H. Carvey

Thanks for a great post, Chad. I'm going to update the plugin to RegRipper to support both XP and Vista subkeys, and then release it.

Posted June 24, 2011 at 4:32 PM | Permalink | Reply

Rune Nordvik

The OpenSavePidlMRU in W7 seams to use PIDLs (Pointer ID Lists) to save which files has been opened or saved and more. The first BYTE or WORD describe the length of the PIDL, the next DWORD describe the type of PIDL. But the content structure is variable. Some PIDL has strings in Unicode, others in ASCII, and there are some as far as I can see with unknown structures. Have you seen this? And do you know how to parse the unknown structures?
One of the PIDL with unknown structures looks like this:

Posted June 28, 2013 at 1:58 PM | Permalink | Reply

Michael G.

In addition to the key LastVisitedPidMRU, There was also a key called LastVisitedPidMRULegacy in the on a Win 7 machine. It contained a list of 7 applications. Anyone familiar with this key?

Posted June 28, 2013 at 2:57 PM | Permalink | Reply

Michael G.

I used RegRipper v2.8 with comdlg32 v20121008 to parse an ntuser.dat file from a Win 7 machine. The resulting report for the OpenSavePidMRU\\*, \\docx, \\jpg and \\pdf entries contained files described as "Libraries" but the other files were properly listed. When I viewed the key using registry viewer, those files labeled in the regripper output as "Libraries" were found to actually be listed as follows:
For OpenSavePidMRU\\*:
C:\\Users\\\\Documents\\Walkways 2 pg_3.jpg
For OpenSavePidMRU\\docx:
C:\\Users\\\\Documents\\Receipt No 1001.docx
For: OpenSavePidMRU\\jpg:
C:\\Users\\\\Documents\\Walkways 2 pg_3.jpg
For: OpenSavePidMRU\\pdf:
C:\\Users\\\\Documents\\Receipt No 1001.docx
Does anyone know why regripper is reporting the above files and file paths simply as "Libraries"?

Posted June 30, 2013 at 10:51 PM | Permalink | Reply

Chad Tilbury

I was going to recommend you submit a bug report to the RegRipper code page (, but it looks like you already have! This is a great example of why it is important to double-check important artifacts in cases.