La aplicación se bloquea al hablar con Oracle a menos que la ruta ejecutable contenga espacios

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

  •  04-07-2019
  •  | 
  •  

Pregunta

Tenemos un problema con los archivos x con nuestra aplicación .NET. O, mejor dicho, la aplicación híbrida Win32 y .NET.

Cuando intenta comunicarse con Oracle, simplemente muere. Desaparece Va al gran vacío negro en el cielo. Ningún mensaje de registro de eventos, ninguna excepción, nada.

Si simplemente le pedimos a la aplicación que hable con un MS SQL Server en su lugar, lo que tiene el efecto de reemplazar el uso de OracleConnection y las clases relacionadas con SqlConnection y las clases relacionadas, funciona como se esperaba.

Hoy tuvimos un gran avance.

Por alguna razón, un cliente se había dado cuenta de que al colocar todos los archivos de la aplicación en un directorio de su escritorio, también funcionaba como se esperaba con Oracle. Mover el directorio a la raíz de la unidad, o en C: \ Temp o, bueno, alrededor de un poco, reapareció el bloqueo.

Básicamente, era 100% reproducible que la aplicación funcionara si se ejecutaba desde el directorio en el escritorio, y fallaba si se ejecutaba desde el directorio en la raíz.

Hoy nos dimos cuenta de que la diferencia que se contaba era si había un espacio en el nombre del directorio o no.

Por lo tanto, estos directorios funcionarían: 

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

mientras que estos no: 

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

Espero que alguien que esté leyendo esto haya visto un comportamiento similar y tenga un " aha, necesita girar el frob en la configuración del controlador oracle glitz " o similar.

¿Alguien?

Followup # 1: Ok, ahora he procesado la salida procmon, ambos archivos desde que presioné el botón que intenta abrir la ventana que activa la falla de la cascada, y noté que mantienen un registro principalmente, hay algunas pequeñas diferencias cerca de la parte superior de ambos archivos, y siguen un largo camino hacia abajo.

Sin embargo, cuando una ejecución falla, la otra continúa y las siguientes líneas de la salida del registro son las siguientes: 

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

Después de esto, la ejecución de trabajo continúa ejecutándose, y el otro toca los archivos mscorwks.dll unas cuantas veces antes de que los subprocesos se cierren y la aplicación se cierre. Por lo tanto, la ejecución fallida no toca los archivos anteriores.

Seguimiento nº 2: pensé que intentaría actualizar los controladores de cliente de Oracle, pero 10.2.0.1 parece ser la versión más alta disponible para el servidor de Windows 2003 y los clientes de XP.

Seguimiento # 3: Bueno, hemos terminado con una solución de caja negra. Básicamente, encontramos que el problema está relacionado con XPO y Oracle. XPO tiene una tabla de sistema que administra, llamada XPObjectType, con tres columnas: Oid, TypeName y AssemblyName. Debido a la configuración de Oracle en las bases de datos con las que hablamos, los nombres de las columnas fueron OID, TYPENAME y ASSEMBLYNAME. Esto normalmente no sería un problema, excepto que XPO se comunica directamente con la información del esquema y comprueba si la tabla tiene los nombres de columna correctos, y XPO no maneja las diferencias de casos, por lo que ve una tabla XPObjectType con tres columnas desconocidas y ninguna de los que espera.

Exactamente lo que hace XPO ahora realmente no lo sé, pero si eliminé esta tabla y la recrearé con el caso correcto, usando comillas dobles alrededor de todos los nombres de columna para resolver el caso, el problema no se recorta arriba.

Exactamente donde el espacio en el nombre de la carpeta entra en esto, todavía no tengo idea, pero este problema tenía dos niveles:

  1. Evite que la aplicación se bloquee en nuestros clientes, solución a corto plazo
  2. Solucionar el error, solución a largo plazo

En este momento se resuelve el nivel 1, el nivel 2 se volverá a poner en la cola por ahora y se priorizará. De todos modos, estamos enfrentando algunos cambios más grandes en nuestro nivel de datos, por lo que este podría no ser un problema que debamos resolver, al menos si todos nuestros clientes de Oracle verifican que la corrección de la tabla realmente se deshaga del problema.

Aceptaré la respuesta por Dave Markle ya que, aunque Process Monitor (el hermano mayor de File Monitor) en realidad no identifiqué el problema, pude usarlo para determinar que después de mi punto de interrupción en el código de usuario donde XPO había creado la consulta para esta tabla, no se producía ninguna E / S hasta que todas las entradas para el cierre de la aplicación eran registrado, lo que me llevó a creer que era esta mesa la culpable, o al menos influyó en el problema de alguna manera.

Si logro llegar a la causa real de esto, actualizaré la publicación.

¿Fue útil?

Solución

Esto es lo que yo haría. Primero, TRIPLE-verifica que estás viendo el comportamiento que crees que estás viendo. Puedo ver que esto sucede al revés al no usar System.IO.Path para concatenar rutas, pero no como lo estás viendo. Comprueba tres veces que los permisos de los archivos tengan sentido.

A continuación, descargue Filemon de MS y observe lo que sucede el sistema de archivos como su programa golpea estos puntos problemáticos. Puedes filtrar la actividad específica de un archivo (por ejemplo, eliminar la actividad de tu archivo antivirus) para que todo se vea un poco más limpio mientras haces esto. Busque errores de acceso a los archivos utilizando FileMon tanto para el caso de éxito como para el caso de error de su programa. Eso debería indicar a qué archivo se está accediendo y causando el problema. Por ejemplo, si ve un error de FILE_NOT_FOUND al acceder a un nombre de archivo sin sentido, puede estar seguro de que usted o el proveedor están haciendo algo incorrecto, lo que posiblemente conduzca a su problema ...

Otros consejos

Probablemente debería ver si puede reproducir el problema con una aplicación simple que solo intenta abrir una conexión a Oracle. De esa manera, puede estar 100% seguro de que el problema es con OracleConnection o el controlador de Oracle y no con su propio código.

¡Debes obtener una medalla de perseverancia por eso!

  

" Exactamente lo que hace XPO ahora no lo hago   Realmente lo sé, pero si dejo caer esto.   Mesa, y la recrearon con la derecha.   caso, usando comillas dobles alrededor de todos   Los nombres de las columnas para obtener el caso.   derecho, el problema no surge.

     

Exactamente donde el espacio en la carpeta   El nombre entra en esto, todavía no tengo   idea "

Los problemas que obtengo con los espacios en los nombres es que generalmente interpretan el bit antes del espacio como el nombre y el resto como un parámetro. Si ese es el caso, entonces con el nombre simple puede ver " C \ Temp " y es un directorio. Con el nombre espaciado, obtiene " C: \ Archivos de programa " ;, busca " C: \ Program " Y eso no existe. Fallaría, por ejemplo, sobrescribir " C: \ Temp " pero tendría éxito en escribir " C: \ Programa " ;. Me pregunto si aún fallaría con " C: \ Archivos de programa " si hay un archivo o directorio llamado " C: \ Program "

Sospecho que el cliente de oracle es honesto. Tenía un problema que era similar en su naturaleza frustrante.

Si instalamos en máquinas de 64 bits, el cliente se detendría al inicio cuando se conecte a Oracle aunque la aplicación sea de 32 bits. Finalmente, lo rastreamos hasta el hecho de que cierto cliente de Oracle (Ora 10 tuvo un problema con los corchetes en la ruta, por lo que un programa que se ejecuta en archivos de programa funcionaría con archivos de programa (x86) provocó el bloqueo. La actualización de la máquina para usar el 11G el cliente solucionó el problema pero también había algunos parches disponibles de metalink que no están disponibles directamente. Lo que es extraño en su caso es que no obtiene ninguna excepción, pero el comportamiento de mover la aplicación a una nueva carpeta soluciona el problema de una manera similar, por lo que puede estar relacionado.

ORA-12154: TNS: no se pudo resolver el identificador de conexión especificado o ORA-6413: Conexión no abierta.

Enlaces útiles http: / /blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

Detalles de Metalink a continuación.

Metalink Bug 3807408 No se puede autenticar al usuario externamente con una cita en el nombre de usuario

Descripción Si un nombre de usuario autenticado externamente contiene un '(', ')' o '=' entonces el usuario no puede ser autenticado. Además, si un nombre de programa / ruta contiene estos caracteres, Puede que no sea posible conectarse. p.ej:   Los clientes de Windows instalados en un directorio " C: \ Archivos de programa (x86) "   no se puede conectar con      ORA-12154: TNS: no se pudo resolver el identificador de conexión especificado

El sello distintivo de este problema es que la traza de red (nivel 16) muestra el / los problema / s de carácter / s reemplazados por "? " en la traza.

Solución alternativa   Para el problema de autenticación:    cambie el nombre de usuario,   o    no utilice la autenticación del sistema operativo remoto para esos usuarios

Para el problema del programa / directorio:    cambiar el nombre del programa / directorio

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top