У нас есть проблема с 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 создал запрос для этой таблицы, никаких операций ввода-вывода не было, пока все записи для закрытия приложения не были зарегистрированы, что привело меня к мысли, что именно эта таблица был виновником или, по крайней мере, каким-то образом повлиял на проблему.
Если мне удастся понять истинную причину этого, я обновлю сообщение.
