En Windows, ¿qué ocurre explícitamente cuando hago doble clic en un archivo en el Explorador de Windows?

Question

TL; DR

¿Cuáles son las llamadas, de bajo nivel del núcleo del sistema operativo & exactos que se ejecutan cuando un usuario haga doble clic o selecciona un archivo y pulsa la tecla de Enter desde el Explorador de Windows?

---

detalles

Esto puede parecer una pregunta bastante extraño, pero tengo curiosidad por los detalles muy "meollo" de abrir un archivo desde el Explorador de Windows.

En concreto, lo que me gustaría saber, son los de bajo nivel del núcleo del sistema operativo & llamadas exactas que se están ejecutando cuando un usuario haga doble clic o selecciona un archivo y pulsa la tecla de Enter desde el Explorador de Windows.

La razón por la que pregunto es porque tengo una aplicación que permite a los usuarios navegar y buscar archivos basados ​​en metadatos almacenados en una base de datos. Cuando un usuario hace clic en el botón Open que he proporcionado, comienzo un proceso donde el archivo raíz es la ruta al archivo que se ha seleccionado. Además, vale la pena mencionar que estos archivos están en un recurso compartido de red.

Esto ha funcionado durante años, sin embargo, recientemente mi compañía ha migrado a un nuevo servidor de Active Directory y ahora la aplicación se interrumpe para un pequeño grupo de usuarios (1-2%). Lo realmente extraño es que estos los usuarios no pueden abrir este archivo desde mi aplicación, pero pueden buscar la ubicación y abrirlo desde el Explorador de Windows. Cuando mi aplicación intenta abrir el archivo, obtiene una excepción muy genérica que indica que no se pudo encontrar el archivo.

He comprobado tres veces la ruta que está usando la aplicación (para varios archivos) y la ruta no es incorrecta. Verifiqué que mis usuarios tenían, y están, conectados a estas unidades de red antes de abrir los archivos. Todo está configurado correctamente y debería funcionar, pero mi aplicación (o System.Process) no puede "ver" o abrir estos archivos.

¿Qué hace la aplicación Windows Explorer de manera diferente a usar System.Process desde dentro de una aplicación?

---

Para aquellos que deben tener código antes de responder, aquí está el código excepcionalmente lacónico que utilizo para abrir un archivo. De nuevo, esto ha funcionado durante años y, como mejor sé, es cómo permites que Windows abra un archivo desde .Net.

//From within 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" 
} 

---

Una cosa más. Encontré this question en SO, pero no se aplica a esta pregunta. Mi aplicación simplemente intenta abrir archivos PDF y algunos archivos de dibujo de ingeniería. Nada especial, y no debería requerir acceso de administrador. Además, no creo que sea necesaria ninguna autenticación de usuario ya que la mayoría de los usuarios nunca reciben este mensaje y ya se han validado en la red al iniciar sesión y navegar a la ubicación de la red.

Answer 1

¿Cuáles son las llamadas, de bajo nivel del núcleo del sistema operativo & exactos que se ejecutan cuando un usuario haga doble clic o selecciona un archivo y presiona la tecla Intro desde el Explorador de Windows?

Puede probarlo usted mismo. Así es como lo hice: una muestra C# código de programa

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

    }   
} 

Ahora puede ejecutar esta aplicación desde una ubicación predefinida. A continuación, puede usar una aplicación ProcMon de SysInternals para observar las llamadas de bajo nivel. Aquí hay una instantánea del archivo csv que ProcMon generó en mi máquina. He puesto un filtro sólo para incluir path al archivo, que era 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" 
... 

La versión completa de csv está disponible en pastebin. Cada línea en el archivo csv corresponde a una llamada de bajo nivel, además hay otra pelusa que se excluyó debido al filtro estricto en la ruta.

Answer 2

Un modo de falla muy común, y presente en su código, no es establecer el ProcessStartInfo.WorkingDirectory correctamente. Un subconjunto de programas se basa en que Explorer establece el directorio de trabajo predeterminado en el directorio que contiene el archivo y se cae cuando no está configurado.Harán algo imprudente como intentar abrir un archivo de configuración sin especificar el nombre completo de la ruta, que solo funciona si el directorio de trabajo está configurado correctamente.

a solucionar de esta manera:

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

que supone que usted no hace el mismo error de no especificar el nombre de ruta completo para archivo.

Answer 3

La pregunta "TL; DR" es breve y va al grano, pero no estoy seguro de que la respuesta a esa pregunta resuelva su problema. La respuesta de Hans Passant es probablemente mucho más útil. Sin embargo, intentaré proporcionar un poco de información.

Windows tiene varias capas y en este caso las dos capas interesantes son la de Windows Shell activos y de la Servicios del sistema API. Está utilizando Process.Start() de una manera que llamará al ShellExecuteEx en el Shell de Windows. El shell de Windows proporciona una abstracción en la parte superior de Windows donde tiene un escritorio (que realmente es una carpeta en algún disco) y los archivos se tratan como documentos con iconos y verbos para operar en estos documentos. En tu caso, estás usando el verbo Open.

El shell de Windows es bastante complejo y se puede extender, por lo que ShellExecuteEx está haciendo para una ruta particular y el verbo es una nota fácil de responder. Depende de lo que está registrado en la máquina local. Sin embargo, si el archivo es un archivo PDF y el verbo es Open, es de esperar que el shell ejecute cualquier aplicación asociada con la extensión .PDF en el registro.

En Windows 7 se puede examinar y modificar las Asociaciones del archivo en el panel de control > Programas >Programas predeterminados>Establecer asociaciones. Sospecho que si falta el programa asociado con la extensión .PDF puede obtener FileNotFoundException pero no lo he verificado.

Si el shell decide que se debe ejecutar una aplicación, en algún momento llamará a la capa de Servicios del sistema y utilizará la función CreateProcess para crear un nuevo proceso.Para un archivo PDF (dependiendo del registro para .PDF) se creará un proceso ejecutando Acrobat.exe con un único argumento de línea de comando (el archivo que especificó).

Para solucionar el problema, puede escribir en el símbolo del sistema file.pdf (el archivo debería existir) y ver si el shell puede abrir un archivo PDF.

Answer 4

¿Puedes intentar algo como esto usando FileSystemInfo.FullName?

string file = e.Cell.Value.ToString(); 
var fileInfo = new FileInfo(Path.Combine(System.IO.Path.GetDirectoryName(file) + file)); 
if (!fileInfo.Exists) 
{ 
    throw new FileNotFoundException(fileInfo.FullName + " was not found"); 
} 
System.Diagnostics.Process.Start(fileInfo.FullName);