Within Windows, what explicitly happens when I double-click on a file in Windows Explorer?

Question

TL;DR

What are the exact, low-level kernel & OS processes that are being executed when a user either double-clicks or selects a file and presses the Enter key from within Windows Explorer?

---

Details

This may seem like a rather odd question, but I'm curious about the very nitty-gritty details of opening a file from Windows Explorer.

Specifically, what I would like to know are the exact, low-level kernel & OS processes that are being executed when a user either double-clicks or selects a file and presses the Enter key from within Windows Explorer.

The reason I ask is because I have an application that allows for users to browse and search for files based off of meta-data stored in a database. When a user clicks the Open button that I've provided, I start a process where the root file is the path to the file that has been selected. Also, it is worth mentioning that these files are on a network share.

This has worked for years, however, recently my company has migrated to a new Active Directory server and now the application is broken for a very small handful of users (1-2%.) The really odd thing is that these users cannot open this file from my application, but they can browse to the location and open it from Windows Explorer. When my application attempts to open the file, it gets a very generic exception stating that the file couldn't be found.

I've triple checked the path that the application is using (for multiple files) and the path is not incorrect. I've verified that my users have, and are, connected to these network drives before opening the files. Everything is setup correctly and should work but my application (or System.Process) can't "see" or open these files.

What is the Windows Explorer application doing differently than using System.Process from within an application?

---

For those who must have code before answering, here is the exceptionally terse code that I use to open a file. Again, this has worked for years and, as best I know, is how you let Windows open a file from within .Net.

//From my Button-Click Event...
string file = e.Cell.Value.ToString();
try
{
    Process p = new Process();
    p.StartInfo.FileName = file;
    p.StartInfo.Verb = "Open";
    p.Start();
} 
catch (Exception ex)
{
    MessageBox.Show("A problem has occurred while trying to open the doccument."
    + "Please make sure that the file below exists and that you have permission " 
    + "to view it."
    + Environment.NewLine + Environment.NewLine
    + file
    + Environment.NewLine + "---------------" + Environment.NewLine  +
    ex.Message

    );
    //ex.Message states "The system cannot find the file specified"
}

---

One more thing. I found this question on SO but it doesn't/shouldn't apply to this question. My app is simply trying to open PDFs and some engineering drawing files. Nothing fancy, and it shouldn't require admin access. Also, I don't believe any user authentication should be required since most users never get this message and they've already validated themselves on the network by logging in and browsing to the network location.

Answer 1

What are the exact, low-level kernel & OS calls that are being executed when a user either double-clicks or selects a file and presses the Enter key from within Windows Explorer?

You can test it yourself. Here is how I did it: a sample C# program code

class Program
{
    static void Main(string[] args)
    {

    }        
}

Now you can run this application from a predifined location. You can then use a ProcMon application from SysInternals to observe the low-level calls. Here is a snapshot of csv file that was generated by ProcMon on my machine. I have put a filter only to include path to the file, which was c:\test.exe

"Time of Day","Process Name","PID","Operation","Path","Result","Detail"
"14:57:55.3495633","Explorer.EXE","2568","CreateFile","C:\Test.exe","SUCCESS","Desired Access: Generic Read, Disposition: Open, Options: Open Requiring Oplock, Attributes: N, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened"
"14:57:55.3498808","Explorer.EXE","2568","FileSystemControl","C:\Test.exe","SUCCESS","Control: FSCTL_REQUEST_FILTER_OPLOCK"
"14:57:55.3507711","Explorer.EXE","2568","CreateFile","C:\Test.exe","SUCCESS","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
...

Full version of csv is available on pastebin. Every line in the csv file corresponds to a low level call, plus there is other fluff which was excluded due to the strict filter on path.

Answer 2

A very common failure mode, and present in your code, is not setting the ProcessStartInfo.WorkingDirectory properly. A subset of programs rely on Explorer setting the default working directory to the directory that contains the file and fall over when it isn't set. They'll do something unwise like trying to open a config file without specifying the full path name, that only works if the working directory is set correctly.

You fix it like this:

Process p = new Process();
p.StartInfo.FileName = file;
p.StartInfo.WorkingDirectory = System.IO.Path.GetDirectoryName(file);
p.Start();

Which assumes that you don't make the same mistake of not specifying the full path name for file.