Открытие простого OleDB-соединения вызывает исключение OutOfMemory?

Question

У меня возникли проблемы с одним из наших приложений.Это 32-битный процесс .NET 3.5.При запуске мы открываем файл .mdb, чтобы прочитать несколько значений "метаданных".Это работает на сотнях систем, но у нас есть клиент с планшетным компьютером и проблемами.Операционная система - Windows XP Tablet PC SP3, 32 бита, бла-бла-бла.Ничего необычного.Он имеет .NET 3.5 (из Центра обновления Windows) Все обновлено.Ничего необычного.

Поскольку наше приложение выполняет "несколько действий" во время запуска, я создал самое простое консольное приложение из когда-либо существовавших:

namespace TestAccessConnection
{
    class Program
    {
        static void Main( string[] args )
        {
            OleDbConnection connection;
           try
            {
                connection =
                    new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=metadata.mdb;Persist Security Info=False");
                connection.Open();
                connection.Close();
                Console.Read();
            }
            catch ( Exception e )
            {
                Console.WriteLine(e.ToString());
                Console.Read();
            }
        }
    }
}

Результаты:

Если мы выполним этот единственный файл .exe без файла "metadata.mdb" по тому же пути, мы получим очевидный:"файл не найден бла-бла-бла".Это правильно.

Если мы скопируем метаданные (подробнее о метаданных позже), мы получаем следующее:

System.OutOfMemoryException: An exception of type 'System.OutOfMemoryException' has occurred.
  at System.Data.Common.ADP.IsSysTxEqualSysEsTransaction()
  at System.Data.Common.ADP.NeedManualEnlistment()
  at System.Data.OleDb.OleDbConnection.Open()
  at TestAccessConnection.Program.Main(String[] args

примечание:исключение было на испанском, и я перевел его, но содержание осталось прежним, единственными отличиями были "исключение типа", но пространства имен остались нетронутыми

Что содержится в метаданных?:Это простой файл MS ACCESS 2000 с одной таблицей и парой записей (в нем хранятся разные строки подключения MS-SQL в зашифрованном виде), поэтому при запуске мы можем прочитать соединения, расшифровать их и представить список для выбора пользователем различных подключений.Ни одна из этих функций не присутствует (или не выполняется) в созданной мной тестовой программе, поскольку исключение генерируется (по-видимому) при подключении.Open()

Подробнее об этом компьютере, в частности Коробка кажется обычной.Мы переустановили .NET из разных источников (Центр обновления Windows) и dotnetfx.exe (большой файл размером 250 МБ) и даже выполнили "восстановление" из этого большого установщика .net..NET, похоже, работает, поскольку это маленькое консольное приложение нацелено на .NET 3.5.

Зачем нужен этот тест? Причина, по которой консольное приложение делает только это, заключается в том, что наше собственное приложение делает (среди нескольких других вещей), что как только оно начинает выполнять Main(), это одна из первых вещей, которые мы делаем, поэтому я выделил этот фрагмент кода и обнаружил, что там генерируется исключение.Чтобы убедиться, что ни один из наших кодов не имеет к этому никакого отношения, я создал тестовое приложение и обнаружил странное исключение.

А как насчет Google? Я лихорадочно искал в Google /SO /etc.безрезультатно.OutOfMemory - это очень вводящий в заблуждение поисковый запрос, даже в сочетании с oledb и другими "возможными" ключевыми словами ("возможно, я что-то упускаю").Попытка поиска с использованием других частей пространств имен указывает на странные результаты, которые, по-видимому, не связаны с этой конкретной проблемой.

В чем же заключается вопрос? О, это же просто:Есть какие-нибудь идеи?

Поймать Я пытаюсь избежать переустановки всей Windows (что также могло бы решить проблему, учитывая, что эта простая вещь работает на сотнях других компьютеров).Похоже, что коробка не заражена вредоносным ПО или чем-то подобным, это планшетный компьютер, используемый в здравоохранении, поэтому доступ в Интернет, хотя и "открытый", используется редко, если используется вообще.Это не означает, что коробка чиста на 100% (в Windows вы никогда не можете быть уверены).Если вы знаете или сталкивались с этой проблемой (и нашли решение), пожалуйста, просветите меня.

Заранее спасибо!

Answer 1

Это было недоступно уже больше года, и с тех пор я портировал код для использования одного небольшого XML-файла.С тех пор у нас не было никаких проблем.

По сути, приложение запускается, и если оно не обнаруживает XML, оно ищет MDB, если оно находит его, оно пытается открыть его (всегда отслеживая возможные ошибки), если оно может его открыть, оно считывает содержимое и создает XML, сохраняет его и закрывает MDB навсегда :)

На данный момент он работал с более чем 1000 машинами, однако причина ошибки памяти до сих пор неизвестна.