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.
1. Double-click is a term used to describe the process of quickly pressing a mouse button twice while keeping it still. In most cases, a double-click is with the left mouse button and is used to open or execute a file, folder, or software program.
On most systems, double-clicking an icon in the file manager will perform a default action on the object represented by the icon. Double-clicking an application program will launch the program, and double-clicking a file icon will open the file in a default application for that file's type or format.
verb. double-clicked; double-clicking; double-clicks. : to choose (something on a computer screen) by quickly pressing a button on a computer mouse or other device two times. Double-click the icon to start the program.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With