It was a couple of days ago at work. I pressed the keyboard shortcut Winkey+R to open Windows’ Run dialog-box and started typing a file-system path to open. While doing so, the application suggested a couple of paths for me to choose from.

Among these paths, I noticed, was a path to a folder I had previously deleted.

Why is Run suggesting a non-existing path? and how can I remove this path from the drop-down list?

This was the question that triggered my research, whose process and findings I will share in this post.

First Thing - First Aid

Having the above-mentioned question in mind, I didn’t know where to start. The run dialog-box was some magical popup that I knew only as an end-user. I had absolutely no idea how to approach this problem. Luckily, Daniel my team-leader has the answer (or the path to it) to any Windows question.

I simply asked him: “What would you do if you wanted to know how the Run dialog-box auto-completed your typed strings?". In response, he gave me a short intro to Windows’ windows (😐), told me to start by finding the Run window object and set me off.

The Research Process

In hindsight, I can split the research into 3 stages:

1. Identify the process which is responsible for the Run dialog-box;
2. Find the autocomplete-related events performed by this process;
3. Conclude the answer to my question.

1. Identifying the Run dialog-box’s Process

In order to understand where Run stored its saved paths, I needed to first find the process responsible for its dialog-box. Both Process Explorer and Process Monitor from Sysinternals Suite help with window-to-process mapping; they have a nice feature that lets you point a special cursor at a UI window and get the process which created it.

Another tool named Spy++ comes bundled with Microsoft Visual Studio. Compared to Process Monitor and Process Explorer, Spy++ is much more window-oriented and displays the complete window hierarchy of the current session. I decided to go with Spy++ as it was both new to me and felt more accurate for the mission.

Using Spy++ I identified the Run dialog-box’s process. It turned out that this window is named Run and belongs to the explorer.exe process (the gif below shows only the process ID; I inferred the process name using Process Explorer).

2. Tracing explorer.exe’s Auto-Complete Events

My go-to tool for monitoring a process is, well, Process Monitor. Once I knew I should concentrate on explorer.exe, I started capturing events in Process Monitor, opened the Run dialog box and started typing arbitrary paths. Then I used a filter to display only explorer.exe events. The problem is, explorer.exe creates shit-tons of events, non-stop.

I went back to Spy++ looking for more information on the Run window, and noticed its thread ID (TID). With this information, the task of filtering out irrelevant explorer.exe events became much easier.

Even after filtering, there were still many events. Briefly scanning them, I saw a registry-write event referring to a key named RunMRU. Seeing the word “Run”, and recalling that MRU stands for “most recently used”, I figured this might be the place I was searching for.

3. Reaching Conclusions

I went straight to the registry path HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU\MRUList where I found my answer:

This key listed my most recently used paths, and was clearly “feeding” the Run auto-complete feature. The path to the non-existent folder was there – and this is why the Run dialog-box kept suggesting it! Woohooooooooo!

I tested my theory by evicting the non-existent path from the MRU list. I simply entered new paths to the text box until the non-existent path was pushed out. Once the path was no longer in the registry, it never appeared again in the drop down list.

Actually, the MRU mechanism is pretty sweet so I’ll elaborate a bit.

explorer.exe saves 26 paths at each given moment. Why 26? Because each path is saved in a key whose name is a letter between a and z. The “most” part in the “MRU” is encoded in the MRUList key. This is a string consisting of all 26 alphabet letters, the first letter being the newest entry and the last letter being the oldest. This string determines the order of the paths that appear when you hit the down-arrow in the Run dialog-box.

4. A Follow-Up Question

I noticed two scenarios:

1. Run suggests non-existing paths that I once typed;
2. Run suggests existing paths that I never-in-my-life typed.

The first scenario can be explained by the MRU list, but the second still needs clarification. My assumption is that explorer.exe traverses the file-system in real time, and is therefore capable of suggesting paths that were never typed-in. However, I’ll leave it for (someone’s, maybe my) further work.

Summing Up

This short blog post shows how I did a quick research on a mechanism in Windows that I thought was interesting. I found out that Run dialog-box auto-completes file-paths based on a list of 26 most-recently-used paths in the registry.

I believe these questions, that arise from one’s curiosity, are the ones that are most satisfying to answer :) I hope you always stay curious enough to ask questions and restless enough to answer them.