Сбой приложения при разговоре с oracle, если исполняемый путь не содержит пробелов

У нас есть проблема с x файлами с нашим .NET-приложением. Или, скорее, гибридное приложение Win32 и .NET.

Когда он пытается связаться с Oracle, он просто умирает. Пропадает. Идет к большой черной пустоте в небе. Нет сообщений журнала событий, никаких исключений, ничего.

Если мы попросим приложение вместо этого поговорить с MS SQL Server, что приводит к замене использования OracleConnection и связанных с ним классов с SqlConnection и связанными с ними классами, оно работает так, как ожидалось.

Сегодня у нас был прорыв.

По какой-то причине клиент выяснил, что, разместив все файлы приложений в каталоге на своем рабочем столе, он также работал с Oracle. Перемещение каталога вниз в корневой каталог диска или в C:\Temp или, ну, немного, привело к сбою.

В основном это было 100% воспроизводимым, что приложение работало, если оно запускалось из каталога на рабочем столе, и не удалось запустить из каталога в корневом каталоге.

Сегодня мы выяснили, что разница в том, что было подсчитано, было ли место в имени каталога или нет.

Итак, эти каталоги будут работать:

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

тогда как они не будут:

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

Я надеюсь, что кто-то, кто прочитает это, увидит подобное поведение и получит "ага, вам нужно обмануть frob в конфигурации драйвера оракула" или тому подобное.

Кто-нибудь?

Followup # 1: Хорошо, теперь я обработал вывод procmon, оба файла, когда я нажал кнопку, которая пытается открыть окно, которое запускает каскадный сбой, и я заметил что они отслеживают в основном, есть некоторые небольшие различия в верхней части обоих файлов, и они продолжают отслеживать долгий путь вниз.

Однако, когда один запуск выходит из строя, другой продолжает двигаться, и следующие несколько строк выходного файла журнала:

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

После этого рабочий цикл продолжает выполняться, а другой касается файлов mscorwks.dll несколько раз, прежде чем потоки закрываются и приложение закрывается. Таким образом, неудачный прогон не затрагивает вышеуказанные файлы.

Последующее наблюдение # 2:. Я попытался обновить драйверы оракул-клиента, но 10.2.0.1, по-видимому, является самой высокой версией, доступной для клиентов Windows 2003 и XP.

Последующее наблюдение # 3: Ну, у нас получилось решение с черным ящиком. В основном мы обнаружили, что проблема где-то связана с XPO и Oracle. XPO имеет системную таблицу, которую он управляет, называется XPObjectType, с тремя столбцами: Oid, TypeName и AssemblyName. Из-за того, как Oracle настроен в базах данных, с которыми мы разговариваем, имена столбцов были OID, TYPENAME и ASSEMBLYNAME. Обычно это не проблема, за исключением того, что XPO напрямую связывается с информацией о схеме и проверяет, существует ли таблица с именами правильных столбцов, а XPO не обрабатывает разницы в case, поэтому он видит таблицу XPObjectType с тремя неизвестными столбцами и ни один ожидаемых.

Точно то, что XPO делает сейчас, я действительно не знаю, но если я отброшу эту таблицу и заново создала ее в правильном случае, используя двойные кавычки вокруг всех имен столбцов, чтобы получить правильное решение, проблема не обрезает вверх.

Именно там, где в это имя входит пространство в имени папки, я до сих пор не знаю, но эта проблема имела два уровня:

  • Остановить приложение от сбоев у наших клиентов, краткосрочное решение
  • Исправить ошибку, долгосрочное решение

В настоящий момент уровень 1 решен, уровень 2 теперь будет возвращен в очередь и приоритет. В любом случае мы сталкиваемся с некоторыми большими изменениями в нашем уровне данных, поэтому это может быть не проблема, которую нам нужно решить, по крайней мере, если все наши клиенты Oracle подтвердят, что исправление таблицы действительно избавляется от проблемы.

Я согласен с ответом Dave Markle, поскольку хотя Process Monitor (старший брат File Monitor) на самом деле не выявил проблему, я смог используйте его, чтобы определить, что после моей точки останова в пользовательском коде, где XPO создал запрос для этой таблицы, никаких операций ввода-вывода не было, пока все записи для закрытия приложения не были зарегистрированы, что привело меня к мысли, что именно эта таблица был виновником или, по крайней мере, каким-то образом повлиял на проблему.

Если мне удастся понять истинную причину этого, я обновлю сообщение.

Ответы

Ответ 1

Вот что я буду делать. Во-первых, TRIPLE-проверьте, что вы видите поведение, которое, как вы думаете, видите. Я вижу, что это происходит наоборот, не используя System.IO.Path для конкатенации путей, но не так, как вы это видите. Тройка проверки прав доступа к файлам имеет смысл.

Затем загрузите Filemon из MS и посмотрите, что происходит в файловой системе, так как ваша программа попадает в эти проблемные места. Вы можете отфильтровать определенную активность файла (например, удаление активности антивирусных файлов), чтобы все выглядело немного чище, пока вы это делаете. Ищите ошибки доступа к файлу с помощью FileMon как для случая успеха, так и для случая ошибки для вашей программы. Это должно указывать на то, к какому файлу обращаются и что вызывает проблему. Например, если вы видите ошибку FILE_NOT_FOUND, обращаясь к бессмысленному имени файла, вы можете быть уверены, что вы или поставщик делаете что-то неправильно, что может привести к вашей проблеме...

Ответ 2

Вероятно, вы можете увидеть, можете ли вы воспроизвести проблему с помощью простого приложения, которое пытается только открыть соединение с Oracle. Таким образом, вы можете быть на 100% уверены, что проблема связана с OracleConnection или драйвером Oracle, а не с вашим собственным кодом.

Ответ 3

Вы должны получить медаль за упорство в этом!

"Точно, что XPO делает сейчас, я не действительно знаю, но если бы я отказался от этого таблицы, и воссоздал его с правом случай, используя двойные кавычки вокруг всех имена столбцов, чтобы получить случай правильно, проблема не возникает.

Именно там, где пространство в папке имя приходит в это, у меня все еще нет Идея"

Проблемы, которые я получаю с пробелами в именах, это то, что они обычно интерпретируют бит перед пространством как имя, а остальное - как параметр. Если это так, то с простым именем он может видеть "C\Temp", и это каталог. С разнесенным именем он получает "C:\Program Files", ищет "C:\Program" и этого не существует. Например, он не смог бы перезаписать "C:\Temp", но ему удастся написать "C:\Program" . Если у вас есть файл или каталог под названием "C:\Program"

Ответ 4

Я подозреваю, что клиент оракула будет честным. Была проблема, которая была схожа с этим в расстройстве природы.

Если мы установили на 64-битные машины, клиент остановится при запуске при подключении к oracle, даже если приложение 32 бит. В конечном итоге мы отследили тот факт, что определенный клиент оракула (у Ora 10 была проблема с скобками в пути, поэтому программа, работающая под программными файлами, работала под файлами программы (x86), вызвала сбой. Обновление машины для использования 11G клиент исправил проблему, но также были доступны некоторые исправления от metalink, которые не доступны напрямую. В вашем случае странно, что вы не получаете никаких исключений, но поведение переноса приложения в новую папку устраняет проблему аналогичным образом, поэтому могут быть связаны.

ORA-12154: TNS: не удалось определить указанный идентификатор подключения или ORA-6413: соединение не открыто.

Полезные ссылки http://blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

Подробная информация от Metalink ниже.

Metalink Bug 3807408 Не удается выполнить аутентификацию пользователя пользователем с цитатой в имени пользователя

Описание Если внешнее аутентифицированное имя пользователя содержит "(',') 'или' = ' то пользователь не может быть аутентифицирован. Кроме того, если имя/путь программы содержит эти символы, возможно, невозможно подключить. например: Клиенты Windows, установленные в каталоге "C:\Program Files (x86)", не удается подключиться    ORA-12154: TNS: не удалось определить указанный идентификатор подключения

Отличительной чертой этой проблемы является то, что трассировка Net (уровень 16) показывает символ проблемы /s заменен на "?" в трассе.

Обход Для проблемы аутентификации:  Изменение имени пользователя, или  не используйте удаленную аутентификацию ОС для этих пользователей.

Для проблемы с программой/каталогом:  изменить имя программы/каталога