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

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

  •  04-07-2019
  •  | 
  •  

Вопрос

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

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

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

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

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

По сути, было на 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

Я надеюсь, что кто-то, читающий это, видел подобное поведение и подумал: «Ага, вам нужно покрутиться в конфигурации драйвера oracle glitz» или что-то подобное.

Любой?


Продолжение №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: Подумал, что попробую обновить драйверы клиента oracle, но 10.2.0.1, по-видимому, является самой последней версией, доступной для сервера Windows 2003 и клиентов XP.


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

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

При чем здесь пробел в названии папки, я до сих пор понятия не имею, но у этой проблемы было два уровня:

  1. Предотвратить сбой приложения у наших клиентов, краткосрочное решение
  2. Исправьте ошибку, долгосрочное решение

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

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

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

Это было полезно?

Решение

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

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

Другие советы

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

За это вам следует получить медаль за упорство!.

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

Точно, где место в имени папки входит в это, я все еще понятия не имею »

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

Честно говоря, я подозреваю, что клиент Oracle.Была проблема, похожая по своему разочаровывающему характеру.

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

ОРА-12154:TNS: не удалось разрешить указанный идентификатор Connect или ORA-6413:Соединение не открыто.

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

Подробности от Металинк ниже.

Ошибка Metalink 3807408. Невозможно выполнить внешнюю аутентификацию пользователя с помощью кавычки в имени пользователя.

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top