У нас проблема с 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

Я надеюсь, что кто-то, читающий это, видел подобное поведение и имел «ага, вам нужно вертеть лягушку на конфигурации драйвера 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 и Oracle. XPO имеет системную таблицу, которой он управляет, которая называется XPObjectType, с тремя столбцами: Oid, TypeName и AssemblyName. Из-за того, как Oracle настроен в базах данных, с которыми мы говорим, имена столбцов были OID, TYPENAME и ASSEMBLYNAME. Обычно это не является проблемой, за исключением того, что XPO напрямую обращается к информации схемы и проверяет, существует ли таблица с правильными именами столбцов, а XPO не обрабатывает различия в регистре, поэтому он видит таблицу XPObjectType с тремя неизвестными столбцами и ни одного из них. из тех, кого он ожидает.

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

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

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

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

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

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