Arresto anomalo dell'applicazione quando si parla con Oracle a meno che il percorso eseguibile non contenga spazi

StackOverflow https://stackoverflow.com/questions/239622

  •  04-07-2019
  •  | 
  •  

Domanda

Abbiamo un problema con i file x con la nostra applicazione .NET. O meglio, applicazione ibrida Win32 e .NET.

Quando tenta di comunicare con Oracle, muore. Svanisce. Va nel grande vuoto nero nel cielo. Nessun messaggio del registro eventi, nessuna eccezione, niente di niente.

Se invece chiediamo semplicemente all'applicazione di parlare con un MS SQL Server, che ha l'effetto di sostituire l'utilizzo di OracleConnection e delle classi correlate con SqlConnection e le classi correlate, funziona come previsto.

Oggi abbiamo avuto una svolta.

Per qualche ragione, un cliente aveva capito che posizionando tutti i file dell'applicazione in una directory sul suo desktop, funzionava come previsto anche con Oracle. Spostando la directory verso il basso nella radice dell'unità, o in C: \ Temp o, bene, un po ', riapparve l'arresto.

Fondamentalmente era riproducibile al 100% che l'applicazione funzionasse se eseguita dalla directory sul desktop e non funzionava se eseguita dalla directory nella radice.

Oggi abbiamo capito che la differenza che contava era se ci fosse o meno uno spazio nel nome della directory.

Quindi, queste directory funzionerebbero: 

C:\Program Files\AppDir\Executable.exe
C:\Temp Lemp\AppDir\Executable.exe
C:\Documents and Settings\someuser\Desktop\AppDir\Executable.exe

considerando che non dovrebbero: 

C:\CompanyName\AppDir\Executable.exe
C:\Programfiler\AppDir\Executable.exe      <-- Program Files in norwegian
C:\Temp\AppDir\Executable.exe

Spero che qualcuno che legga questo abbia visto un comportamento simile e abbia un "aha, è necessario modificare la vibrazione sulla configurazione del driver glitz oracle" o simile.

Chiunque?

Seguito n. 1: Ok, ho elaborato l'output del procmon ora, entrambi i file da quando ho premuto il pulsante che tenta di aprire la finestra che innesca l'errore a cascata, e ho notato che tengono traccia per lo più, ci sono alcune piccole differenze nella parte superiore di entrambi i file e tengono traccia di molta strada.

Tuttavia, quando una corsa fallisce, l'altra continua e le prossime righe dell'output del registro sono queste: 

ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 274 432, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 233 472, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O

Successivamente, l'esecuzione di lavoro continua a essere eseguita e l'altra tocca i file mscorwks.dll alcune volte prima della chiusura dei thread e della chiusura dell'app. Pertanto, l'esecuzione non riuscita non tocca i file sopra.

Seguito n. 2: ho pensato di provare ad aggiornare i driver del client Oracle, ma 10.2.0.1 è apparentemente la versione più alta disponibile per server Windows 2003 e client XP.

Seguito n. 3: Bene, siamo finiti con una soluzione black-box. Fondamentalmente abbiamo scoperto che il problema è da qualche parte correlato a XPO e Oracle. XPO ha una tabella di sistema che gestisce, denominata XPObjectType, con tre colonne: Oid, TypeName e AssemblyName. A causa della configurazione di Oracle nei database con cui parliamo, i nomi delle colonne erano OID, TYPENAME e ASSEMBLYNAME. Questo di solito non sarebbe un problema, tranne per il fatto che XPO parla direttamente con le informazioni dello schema e controlla se la tabella è lì con i nomi delle colonne giuste, e XPO non gestisce le differenze maiuscole, quindi vede una tabella XPObjectType con tre colonne sconosciute e nessuna di quelli che si aspetta.

Esattamente quello che fa XPO ora non lo so davvero, ma se ho lasciato cadere questa tabella e l'ho ricreata con il caso giusto, usando le doppie virgolette attorno a tutti i nomi delle colonne per ottenere il caso giusto, il problema non si ritaglia up.

Esattamente dove lo spazio nel nome della cartella arriva in questo, non ne ho ancora idea, ma questo problema aveva due livelli:

  1. Impedisci l'arresto anomalo dell'applicazione ai nostri clienti, soluzione a breve termine
  2. Correzione del bug, soluzione a lungo termine

In questo momento il livello 1 è stato risolto, il livello 2 verrà rimesso in coda per ora e avrà la priorità. Stiamo comunque affrontando alcune importanti modifiche al nostro livello di dati, quindi questo potrebbe non essere un problema che dobbiamo risolvere, almeno se tutti i nostri clienti Oracle verificano che la correzione della tabella risolva effettivamente il problema.

Accetterò la risposta di Dave Markle dal momento che Process Monitor (il fratello maggiore di File Monitor) in realtà non ho individuato il problema, sono stato in grado di usarlo per determinare che dopo il mio punto di interruzione nel codice utente in cui XPO aveva creato la query per questa tabella, nessun I / O è accaduto fino a quando tutte le voci per la chiusura dell'applicazione erano registrato, il che mi ha portato a credere che fosse il colpevole di questa tabella, o almeno influenzato il problema in qualche modo.

Se riesco ad arrivare alla vera causa di ciò, aggiornerò il post.

È stato utile?

Soluzione

Ecco cosa farei. Innanzitutto, controlla TRIPLO di vedere il comportamento che pensi di vedere. Riesco a vederlo accadere viceversa non usando System.IO.Path per concatenare percorsi, ma non come se lo vedessi. Controlla tre volte che le autorizzazioni dei file abbiano senso.

Successivamente, scarica Filemon da MS e guarda cosa sta succedendo il filesystem mentre il tuo programma colpisce questi punti problematici. Puoi filtrare l'attività specifica del file (rimuovendo l'attività del file antivirus, ad esempio) per rendere tutto un po 'più pulito mentre lo fai. Cerca errori di accesso ai file utilizzando FileMon sia per il caso di successo che per il caso di errore per il tuo programma. Ciò dovrebbe indicare a quale file si accede e che causa il problema. Ad esempio, se visualizzi un errore FILE_NOT_FOUND durante l'accesso a un nome di file senza senso, puoi essere certo che tu o il venditore state facendo qualcosa di sbagliato, probabilmente portando al vostro problema ...

Altri suggerimenti

Probabilmente dovresti vedere se riesci a riprodurre il problema con una semplice applicazione che tenta solo di aprire una connessione a Oracle. In questo modo puoi essere sicuro al 100% che il problema riguarda OracleConnection o il driver Oracle e non con il tuo codice.

Dovresti ottenere una medaglia per la perseveranza per questo!.

  

" Esattamente quello che fa XPO adesso no   lo so davvero, ma se lo avessi lasciato cadere   tavolo e ricreato con il diritto   caso, usando virgolette doppie in tutto   i nomi delle colonne per ottenere il caso   giusto, il problema non si risolve.

     

Esattamente dove lo spazio nella cartella   il nome arriva, non ne ho ancora   idea "

Il problema che ho con gli spazi nei nomi è che generalmente interpretano il bit prima dello spazio come il nome e il resto come parametro. In tal caso, con il semplice nome è possibile visualizzare " C \ Temp " ed è una directory. Con il nome distanziato, ottiene " C: \ Programmi " ;, cerca " C: \ Program " e quello non esiste. Ad esempio, non sarebbe possibile sovrascrivere " C: \ Temp " ma riuscirebbe a scrivere " C: \ Program " ;. Mi chiedo se fallirebbe comunque con " C: \ Programmi " se esiste un file o una directory denominata " C: \ Program "

Sospetto che il client Oracle sia onesto. Aveva un problema che era simile nella sua natura frustrante.

Se installato su macchine a 64 bit, il client si fermerebbe all'avvio quando si connetteva a Oracle anche se l'app era a 32 bit. Alla fine lo abbiamo rintracciato al fatto che un certo client Oracle (Ora 10 aveva un problema con le parentesi nel percorso, quindi un programma in esecuzione sotto i file di programma avrebbe funzionato sotto i file di programma (x86) ha causato l'arresto anomalo. L'aggiornamento della macchina per utilizzare l'11G il client ha risolto il problema ma c'erano anche alcune patch disponibili da metalink che non sono direttamente disponibili. La cosa strana nel tuo caso è che non ottieni alcuna eccezione, ma il comportamento di spostare l'applicazione in una nuova cartella risolve il problema in modo simile, quindi può essere correlato.

ORA-12154: TNS: impossibile risolvere l'identificatore di connessione specificato o ORA-6413: Connessione non aperta.

Link utili http: / /blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

Dettagli da Metalink qui sotto.

Metalink Bug 3807408 Impossibile autenticare esternamente l'utente con citazione nel nome utente

Descrizione Se un nome utente autenticato esternamente contiene un '(', ')' o '=' quindi l'utente non può essere autenticato. Inoltre, se un nome / percorso del programma contiene questi caratteri, esso potrebbe non essere possibile connettersi. per esempio:   Client Windows installati in una directory " C: \ Programmi (x86) "   non riesco a connettersi con      ORA-12154: TNS: impossibile risolvere l'identificatore di connessione specificato

Il segno distintivo di questo problema è che la traccia Net (livello 16) mostra il / i carattere / i problema / i sostituito / i da un "quot?" nella traccia.

Per risolvere il problema   Per il problema di autenticazione:    cambia nome utente,   o    non utilizzare l'autenticazione del sistema operativo remoto per quegli utenti

Per il problema di programma / directory:    cambia il nome del programma / directory

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top