У нас проблема с x-файлами в нашем приложении .NET. Вернее, гибридное приложение Win32 и .NET.
Когда он пытается связаться с Oracle, он просто умирает. Пропадает. Идет к большой черной пустоте в небе. Нет сообщений в журнале событий, нет исключений, нет ничего.
Если вместо этого мы просто попросим приложение подключиться к серверу MS SQL, который заменяет использование 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
Я надеюсь, что кто-то, читающий это, видел подобное поведение и имел "ага, вам нужно вертеть лягушку на конфигурации драйвера oracle glitz" или подобное.
Любой
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 несколько раз, прежде чем потоки закрываются и приложение закрывается. Таким образом, неудачный запуск не затрагивает вышеуказанные файлы.
Followup # 2: Думаю, я бы попытался обновить драйверы клиента oracle, но 10.2.0.1, очевидно, является самой высокой версией, доступной для сервера Windows 2003 и клиентов XP.
Последовательность # 3: Ну, мы закончили с решением черного ящика. В основном мы обнаружили, что проблема где-то связана с XPO и Oracle. XPO имеет системную таблицу, которой он управляет, которая называется XPObjectType, с тремя столбцами: Oid, TypeName и AssemblyName. Из-за того, как Oracle настроен в базах данных, с которыми мы говорим, имена столбцов были OID, TYPENAME и ASSEMBLYNAME. Обычно это не является проблемой, за исключением того, что XPO напрямую обращается к информации схемы и проверяет, существует ли таблица с правильными именами столбцов, а XPO не обрабатывает различия в регистре, поэтому он видит таблицу XPObjectType с тремя неизвестными столбцами и ни одного из них. из тех, кого он ожидает.
Что именно XPO делает сейчас, я не знаю, но если я отбросил эту таблицу и воссоздал ее с правильным регистром, используя двойные кавычки вокруг всех имен столбцов, чтобы получить правильный регистр, проблема не обрезается до.
Точно, где место в имени папки входит в это, я все еще понятия не имею, но у этой проблемы было два уровня:
- Остановите сбой приложения у наших клиентов, краткосрочное решение
- Исправить ошибку, долгосрочное решение
В настоящее время уровень 1 решен, уровень 2 будет помещен обратно в очередь на данный момент и имеет приоритет. В любом случае, мы сталкиваемся с некоторыми более значительными изменениями в нашем уровне данных, так что это может и не быть проблемой, которую нам нужно решать, по крайней мере, если все наши клиенты Oracle проверят, что исправление таблицы действительно устраняет эту проблему.
Я приму ответ от Дейва Маркла , поскольку хотя Process Monitor (старший брат File Monitor) на самом деле не определил проблему, я смог использовать его, чтобы определить, что после моей точки останова в коде пользователя, в котором XPO создал запрос для этой таблицы, ввода-вывода не происходило до тех пор, пока все записи для закрытия приложения не были зарегистрированы, что заставило меня поверить, что именно эта таблица была виновником или, по крайней мере, повлияла проблема как-то.
Если мне удастся выяснить истинную причину этого, я обновлю сообщение.