Tengo un exe Delphi 2010 que inicia un segundo exe. En el segundo exe, hay un cuadro de diálogo que llama a openDialog.execute. Cuando esto se ejecuta en Windows 2008 Enterprise R2 bajo un escritorio remoto, se ejecuta como se esperaba, , pero cuando se ejecuta como una aplicación remota, tan pronto como aparece el diálogo de archivo, la aplicación se cuelga, convirtiendo todas las ventanas de la aplicación en blancas. La única forma de salir de él es terminar la aplicación. Traté de reemplazar TOpenDialog con TFileOpenDialog, los resultados son los mismos. He buscado modificar el archivo RDP que inicia la aplicación principal, pero no veo ningún parámetro que pueda marcar la diferencia. ¿Alguien ha visto alguna vez este tipo de comportamiento?Delphi TOpenDialog se cuelga en Windows 2008 cuando se ejecuta como aplicación de escritorio remota
2010.07.13 Actualizado
Ésta es reproducible mediante un ejemplo sencillo. Hay dos archivos ejecutables en el ejemplo. El primero es un iniciador de archivos, llamado m_module.exe, que contiene una edición, un botón y el siguiente código. Puedo cambiar el nombre del archivo ejecutable en la edición para que coincida con el segundo ejecutable antes de hacer clic en el botón de inicio:
procedure TForm1.Button1Click(Sender: TObject);
begin
ShellExecute(Handle, 'open', stringToOLEstr(edit1.text) , nil, nil, SW_SHOWNORMAL) ;
end;
procedure TForm1.FormShow(Sender: TObject);
begin
edit1.text:=application.exename;
end;
El segundo ejecutable contiene un botón y el código de abajo:
procedure TForm1.Button1Click(Sender: TObject);
begin
OpenDialog1.execute;
end;
La primera El módulo se inicia desde un archivo RDP.
2010.07.14 Actualizado
He descubierto que si puedo copiar los siguientes archivos DLL:
thumbcache.dll
dtsh.dll
wkscli.dll
de la carpeta \ Windows \ System32 en la carpeta de la aplicación, se elimina el problema.
he descubierto además que el cambio de los niveles de propiedad y permisos de estos archivos DLL en la carpeta \ Windows \ System32 de TrustedInstaller al grupo del administrador tiene el mismo resultado (copiarlos en el directorio de la aplicación está cambiando la propiedad y el permiso creo)
Para confirmar esto, verifiqué que los errores volvieron a aparecer si cambié los niveles de propiedad y permisos a TrustedInstaller fuera del grupo del Administrador.
Parece que se trata de un problema de acceso de algún tipo. Tal vez esto ayude a descubrir la causa del problema.
2010.07.18 Actualizado
Parte de la información adicional que pueda ser útil (proporcionado por el Embarcadero):
En este artículo de MSDN para GetWindowsDirectory http://msdn.microsoft.com/en-us/library/ms724454%28VS.85%29.aspx documenta un comportamiento interesante de aplicaciones que se ejecutan en Servicios de Terminal Server. Si bien GetWindowsDirectory no se está llamando directamente, la zona de pruebas del directorio del sistema de Windows por usuario podría estar causando algún tipo de problema. Tal vez uno de los archivos DLL en la cadena de llamadas a GetOpenFileNameA está tratando de hacer referencia a la DLL real en el directorio real del sistema en lugar de la sandboxed, lo que causa una violación de los derechos. Es solo especulación, pero vale la pena investigar.Si pudieras trabajar con el SysInternals Process Monitor o el Process Explorer en el servidor, deberías poder ver commdlg32 y las otras DLL en el seguimiento de pila que se está cargando.
Todas las aplicaciones heredadas (es decir, no todas las aplicaciones creadas para Terminal Services o Remote Desktop Services) se ejecutan bajo una capa de compatibilidad de aplicaciones. Consulte este artículo de MSDN http://msdn.microsoft.com/en-us/library/cc834995%28VS.85%29.aspx. El indicador IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE se define en Windows.PAS. Para propósitos de prueba se puede añadir a la cabecera PE de la aplicación mediante la adición de Windows a la aplicación de las APLICACIONES sección y justo debajo de la sección USOS puesto:
{$ SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}
Esto hará que su aplicación para eludir la compatibilidad capa. Actualmente estoy investigando si los procesos generados (por ejemplo, su segundo exe) retienen todos los derechos y configuraciones de la aplicación definida en RDS.
¿Funciona si inicia la segunda aplicación directamente? –
¿Monitores múltiples en la máquina en cuestión? Sospecho que el Diálogo Abierto se está abriendo en el área del Segundo Monitor y no en la Ventana del Escritorio Remoto. Intenta presionar -Alt-Space-M- y luego usa las teclas de flecha para volver a mostrar el cuadro de diálogo. –
madExcept reports EAccessViolation. ¿Puedes comentar cómo esto se correlaciona con Hang? – Alex