Delphi TOpenDialog si blocca in Windows 2008 quando viene eseguito come applicazione desktop remota

Question

Ho un exe Delphi 2010 che avvia un secondo exe. Nel secondo exe, c'è una finestra di dialogo che chiama openDialog.execute. Quando viene eseguito in Windows 2008 Enterprise R2 su un desktop remoto, viene eseguito come previsto, ma quando viene eseguito come applicazione remota, non appena viene visualizzata la finestra di dialogo del file, l'applicazione si blocca, rendendo bianche tutte le finestre dell'applicazione. L'unico modo per uscirne è terminare l'applicazione. Ho provato a sostituire TOpenDialog con TFileOpenDialog, i risultati sono gli stessi. Ho esaminato la modifica del file RDP che avvia l'applicazione principale, ma non posso vedere nessun parametro che possa fare la differenza. Qualcuno ha mai visto questo tipo di comportamento prima?

---

2010.07.13 Aggiornato

Questo è riproducibile con un semplice esempio. Ci sono due file eseguibili nell'esempio. Il primo è un file launcher, chiamato m_module.exe, che contiene una modifica, un pulsante e il codice seguente. A cambiare il nome del file eseguibile nella modifica in modo che corrisponda alla seconda eseguibile prima di fare clic sul pulsante di lancio:

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; 

Il secondo file eseguibile contiene un pulsante e il codice qui sotto:

procedure TForm1.Button1Click(Sender: TObject); 
begin 
    OpenDialog1.execute; 
end; 

La prima il modulo viene lanciato da un file RDP.

2010.07.14 Aggiornato

ho scoperto che se copio le seguenti DLL:

thumbcache.dll 
dtsh.dll 
wkscli.dll 

dalla cartella \ Windows \ System32 nella cartella dell'applicazione, il problema viene eliminato.

Ho inoltre scoperto che la modifica della proprietà e dei livelli di autorizzazione di queste dll nella cartella \ Windows \ System32 da TrustedInstaller al gruppo dell'Amministratore ha lo stesso risultato (Copiarle alla directory dell'applicazione sta cambiando la proprietà e l'autorizzazione credo)

a conferma di ciò, ho verificato che gli errori sono riapparsi se ho cambiato il livello di proprietà e di autorizzazione di nuovo a TrustedInstaller lontano dal gruppo di amministratori.

Quindi sembra che questo sia un problema di accesso di qualche tipo. Forse questo aiuterà a scoprire la causa del problema.

2010.07.18 Aggiornato

Alcuni ulteriori informazioni che potrebbero essere utili (fornita da Embarcadero):

questo articolo MSDN per GetWindowsDirectory http://msdn.microsoft.com/en-us/library/ms724454%28VS.85%29.aspx documenta un comportamento interessante di applicazioni in esecuzione in Servizi terminal. Mentre GetWindowsDirectory non viene chiamato direttamente il sandboxing della directory di sistema di Windows per ogni utente potrebbe causare qualche tipo di problema. Forse una delle DLL nella catena chiamata a GetOpenFileNameA sta cercando di fare riferimento alla DLL reale nel vero directory di sistema al posto di quello sandbox provocando così una violazione dei diritti. E 'solo speculazione, ma vale la pena indagare.Se si è riusciti a far funzionare SysInternals Process Monitor o Process Explorer sul server, dovrebbe essere possibile visualizzare commdlg32 e le altre DLL nello stack trace caricato.

Tutte le applicazioni legacy (ovvero tutte le applicazioni non create per Servizi terminal o Servizi Desktop remoto) vengono eseguite in un livello di compatibilità delle applicazioni. Vedere questo articolo MSDN http://msdn.microsoft.com/en-us/library/cc834995%28VS.85%29.aspx. Il flag IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE è definito in Windows.PAS. A scopo di verifica è possibile aggiungerlo alla intestazione PE dell'applicazione con l'aggiunta di Windows per la vostra applicazione di USI sezione e proprio sotto put sezione utilizza:

{$ SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}

Questo farà sì che l'applicazione per bypassare la compatibilità strato. Attualmente sto esaminando se i processi generati (ad es. Il secondo exe) conservano tutti i diritti e le impostazioni dell'applicazione definiti in RDS.

Answer 1

Rapporti Windows AV (c0000005) nel modulo thumbcache.dll.

Penso che thumbcache.dll abbia qualcosa a che fare con la creazione/memorizzazione nella cache di miniature per i file. Costruire miniature può significare utilizzare estensioni di terze parti a Explorer, che potrebbero non comportarsi bene con RDP.

Provalo su sistema pulito. Utilizzare VMWare o una macchina virtuale simile per configurare la configurazione di prova.

P.S. Vedi anche questo articolo: How to debug application’s hang? Ma penso che il blocco sia solo la conseguenza di un altro problema nel tuo caso.

Answer 2

Si consiglia di utilizzare lo strumento Process Explorer per visualizzare le proprietà del processo. Controllare, che esattamente DLL sono caricati in entrambi i casi (è possibile farlo selezionando il processo e aprendo il riquadro inferiore nella vista moduli).

È inoltre possibile utilizzare lo strumento Process Monitor per monitorare l'avvio del processo (di nuovo: in entrambi i casi) e vedere eventuali riferimenti alle DLL in questione.

Answer 3

FWIW, abbiamo una situazione simile, ma è determinata da un'esigenza di sicurezza e non da un arresto anomalo. Quando la nostra app viene eseguita tramite Citrix, è vietato mostrare le normali finestre di dialogo "Apri" o "Salva con nome". Quindi abbiamo laminato il nostro. Ha una combinazione di lettere di unità (solo unità locali), selettore di cartella (limitato alle unità approvate), selettore nome file e casella di modifica nome file.

Per noi, questo risolve tutti i problemi di directory attivi e mantiene la sicurezza felice. E impedisce agli utenti di provare a rilasciare file nel nostro filesystem o vedere cose che non dovrebbero.

Se non sono in esecuzione nella sandbox, vengono mostrate le normali finestre di dialogo dei file di Windows. Una funzione wrapper ci permette di chiamarlo da qualsiasi luogo e lasciare la decisione "sandboxed vs windows" in un punto.

Answer 4

Sembra che tu abbia ristretto il tuo problema a un problema di accesso di qualche tipo, quindi la spiegazione seguente potrebbe non aiutarti. Ma ci sembra esistere un problema con le finestre popup su RemoteApp e potevo immaginare che potrebbe portare (almeno in teoria) per un problema simile, è per questo che vorrei menzionare: http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/0a88919f-2d72-4340-abd7-fbe0e9545f25/

A quanto pare l'ordine Z delle finestre non è sempre corretto quando si utilizza RemoteApp. Nel tuo caso, TOpenDialog dovrebbe essere una finestra popup modale. A causa del bug, potrei immaginare che TOpenDialog potrebbe apparire in background. La finestra principale rimarrebbe in primo piano ma sarebbe disabilitata in quanto TOpenDialog è modale. Windows potrebbe quindi non sapere come ridisegnare una finestra disabilitata e semplicemente disegnare una casella bianca.

Answer 5

Stavamo avendo problemi sulla OpenDialog.Execute, ma solo su un computer - e sembrava essere casuale ho scoperto che l'aggiunta del exe di Windows DEP potrebbe risolvere il problema non abbiamo avuto problemi in quanto cambiarla

ecco il link su come modificare le impostazioni di Windows DEP http://www.itechtalk.com/thread3591.html

Si tratta di una soluzione - se qualcuno sa come mantenere la felice DEP si prega di aggiungere un commento qui sotto

Answer 6

E 'l'ordine Z non è corretto (che vedo spesso in Citrix, senza avere una correzione adeguata) sarebbe comunque possibile chiudere il modulo con ctrl-F4 o alt-f4. Inoltre, l'applicazione non "non risponde". A volte l'ordine si correggerà quando si passa da un'attività all'altra