• Updates to the RecentDocs Key in Windows 10

    Posted on March 5, 2019 by Lee Whitfield in Technical Articles.

    I’ve been revisiting things in Windows 10 recently. We’ve seen a few things change that we have taken for granted in previous versions so I’ve been investigating things.

    In my most recent efforts, I’ve come to the RecentDocs key in the Windows registry. For those that are unaware, this key lies in each user’s NTUSER.DAT file under their user profile. The path for the key is “NTUSER.DAT\Software\Microsoft\Windows\Current Version\Explorer\RecentDocs”. Under this key we see a list of recently accessed files (in hex) with a number assigned. Also in this key we have a Most Recently Used (MRU) list. This list gives the access order of the files. In the example below, we can see that the value MRUListEx starts with 33. When we convert this from hex we get 51, the item that is highlighted. The hex for item 51 would translate to the name of a file.

    What you’ll also notice is that the RecentDocs key has subkeys for each extension too. Each of those contains their own MRUListEx for the specific extension as seen in the picture below.

    So we have duplicate data. Files that appear in the top-level RecentDocs key, should also have an entry in their individual file extension subkey too. This means that a text file should appear in both RecentDocs and also RecentDocs\.txt. Note, that there is also a subkey specific to folders.

    What is not shown in the screenshots above is the last-written dates and times associated with the keys. Why is this important? The last-written time has, historically, been used to determine when the most recent file in the MRUListEx value was accessed. For example, In the picture below, the MRUListEx shows 0x33 (51) as being the most recently accessed file. The last write timestamp for the RecentDocs key shows 2019-03-05 17:26:46. Meaning that the file at position 51 was last opened at that time.

    This is the long-held belief anyway. The problem is that this isn’t necessarily true.

    Take the following example. At 12:00pm I open a text file. An entry is added to the MRUListEx in both the RecentDocs key and the .txt file extension subkey. The last written time of both keys are also updated to/at that time. At 12:10pm I go into Registry Explorer and delete either another subkey (.docx for example), or a value referring to another file in the RecentDocs key, and what happens? The last write time for RecentDocs is updated. This now means that the text file is still the most recently accessed file in both MRUListEx lists (RecentDocs and .txt), but it now appears to have two last-accessed times, 12:00pm (from the .txt subkey) and 12:10pm (from the RecentDocs key). However, the file was never actually accessed at 12:10pm. Therefore, our trust in the date and time that the file was opened diminishes somewhat. In the pictures below, I provide another example. In the top picture you can see that the most recently used folder, under the RecentDocs key, was “testfolder6” with a last accessed 17:26:46. However, in the second picture, the Folder key tells us that the same folder was access at 17:16:44, not 17:26:46.

    Which one is accurate? The Folder subkey. I purposely deleted another subkey belonging to a different file type and this behavior updated the last written time for the RecentDocs key.

    Now, at this point, the RecentDocs key is “lying” to us. Well, not really, just our interpretation of the data is wrong, but you know what I mean. Is there anything we can do to make the Folder subkey lie to us too? Of course there is. We can just delete once of the values inside that subkey. So, if I delete value 0 in the picture above, the last-written time of the Folder subkey is updated. This means that we cannot rely on the last-written times of the RecentDocs key or any of its subkeys without verifying those accesses elsewhere.

    Is this likely to happen? Maybe not, but this is something to watch for. Note that this is NOT a Windows 10 only issue. going back, this seems to affect all versions of Windows.

    Now, Windows 10-specific items. What about how the RecentDocs keys are populated? Can we trust those? Well, it depends.

    First, a slight detour. In Windows 10, if you right-click in explorer, select “New” and then select a file type, you get a new file. Surprising? No. But what else happens when you do this? A shortcut (lnk) file for that newly created file is automatically created in the user profile under the “Recent” folder. Not only that, but a shortcut file is also automatically created for the parent folder.

    What about folders? Create a new folder and shortcut file is automatically generated for the folder you created, the parent folder and the grandparent folder. Go test it for yourself.

    So why the detour to talk about shortcut files? Because the RecentDocs key now behaves in the exact same way. If you create a new file, an entry is made in the RecentDocs key and in the relevant extension’s subkey. This file does not have to be opened to generate these entries. In addition entries being created for the created file, entries are also created for the parent folder of the created file, assuming that those entries did not already exist for that folder.

    The same goes for folder creation. Create a folder and the RecentDocs key creates an entry for the created folder, plus the parent folder (if an entry doesn’t already exist), and the grandparent folder (if an entry doesn’t already exist).

    Pretty interesting, right? But what is perhaps more interesting is the order in which this happens. If you create a file or a folder, that entry goes into the RecentDocs key first, followed by the parent folder and, if applicable, the grandparent folder. This means that if you create the file “MyFolder\MyText.txt”, the last write time of the RecentDocs key will relate to the file creation, but the MRUListEx value will show “MyFolder” being the most recently used item, not “MyText.txt”. However, the .txt subkey will still show show “MyText.txt” as the most recently used txt file, and the last write time of the .txt subkey will still apply to that file.

    Then, to make things more confusing, if you are not creating a file, but simply opening a file, similar behavior is seen. If I now go and open “MyText.txt” the RecentDocs key doesn’t show that file as the most recently accessed item, instead it shows the parent folder of “MyFolder”. This means that in most cases the item topping the RecentDocs MRUListEx value will be a folder, you’ll need to go to the subkeys for the file extension for the time relating to the files themselves.

    Now, there is a caveat to this. This behavior doesn’t appear to occur when accessing files that exist directly on the Desktop, or on the user’s Documents folder. My initial thought is that this is due to them being shell folders. However, it continues to apply to subfolders.

    Finally, just because I don’t know if anyone has ever addressed this, accessing two different items with the same name will not create separate RecentDocs entries. If I access MyText.txt from my Desktop and then open a completely different file named the same thing from my USB drive, there is only one entry in the RecentDocs key. The last write time for the .txt subkey will show when the file on the USB was accessed.

    Hope this is useful to someone when you start seeing variances in the RecentDocs key.

    EDIT: I forgot to mention that the RecentDocs\Folders subkey only ever seems to be populated when a child item is accessed (or when child folders are created as discussed above). The simple action of opening a folder does not populate this key.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.