Казалось бы, случайные сбои с VB.NET и COM Interop

Question

Я подумываю переписать новое приложение VB.NET в VB 6.

Приложение работает под терминальными службами и интенсивно использует COM.

По какой-то причине в приложении возникает странная странность -

• Ошибки нарушения произвольного доступа (анализ исключений WinDbg указывает на dll как comdlg32.dll, mscorwks)
• Случайные ошибки переполнения буфера (тоже самое)
• Случайные ошибки в целом - например, эта строка в Form.Load иногда выдает - Me.Icon = Resources.MyIcon

Я следовал всем возможным советам, касающимся ресурсов, сбора мусора, схем утилизации и т. Д. Это, похоже, не приносит никакой пользы.

Я думаю, что есть проблемы с оборудованием. Это работает на виртуальной машине Win2k3 под терминальными службами. Базовая серверная ОС - Win2k3 с 64 ГБ оперативной памяти. На сервере есть много виртуальных машин, каждая из которых работает со своим собственным «материалом» (Exchange и т. Д.).

Либо проблемы с оборудованием, либо среда .NET не так проста для программирования, как можно подумать.

Если бы аппаратное обеспечение было каким-то образом проверено (совершенно другая история), и приложение продолжало вести себя как таковое, было бы целесообразным выбрать (переписать ближе к металлу)?

Я не большой поклонник виртуальных машин и сомневаюсь в их целостности. (Особенно на огромных серверах.)

Редактировать - Спасибо всем за ответы. Проблема оказалась в одном приложении .NET .DLL, который не был нацелен на код x86. Все COM-объекты 32-битные, ОС 64-битная, поэтому мое приложение .NET должно быть ориентировано на 32-битные. (Это объясняет, почему мои примеры приложений VB6 всегда работали. Не то, чтобы я действительно хотел пойти по этому пути в любом случае.)

Answer 1

Установите файлы PDB и используйте "Debug Diagnostics Tool 1.1" для мониторинга вашего приложения, для выявления случаев утечки.

Просмотреть это тоже "Хорошие инструменты для анализа помех реестра COM-объектов?"

Answer 2

Есть ли вероятность, что вы можете воспроизвести проблему с помощью небольшого приложения? Без виртуальной машины или терминальных служб?

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

Переписать его в VB6 было бы ужасной тратой, если он все еще не работает ...

Answer 3

То есть вы работаете под терминальными службами на одной из виртуальных машин? Сколько других пользователей TS на той же виртуальной машине? Я бы больше беспокоился об особенностях терминальных сервисов, чем об особенностях виртуальных машин. Но TS на виртуальной машине, вероятно, имеет большой успех. Обычно мы используем одну виртуальную машину для переносимости / DR или «голый металл» для машин TS.

Какие COM-объекты? Вы определенно открыты для большего количества проблем с производительностью, так как вам нужно пройти через COM-взаимодействие. И если сами COM-объекты не являются вежливыми в терминальных службах ...

ОК, значит, у вас есть несколько пользователей TS на машине (забудьте о ВМ, прямо сейчас). Если эти COM-объекты ведут себя так, как будто они владеют машиной, потому что одновременно может быть зарегистрирован только один пользователь - BAM. Например, скажем, COM-объект (особенно что-то огромное, такое как Corel или Word, где COM-объект представляет собой интерфейс к огромной подсистеме), отправляется на чтение некоторых из его файлов конфигурации или библиотеки форм или чего-то еще. Как правило, это единственный, кто делает это, поэтому он никогда не будет заблокирован или заблокирован или что-либо еще. Внезапно у вас есть несколько пользователей, попавших в один и тот же (локальный) файл. Это похоже на попытку запуска приложения из общего сетевого ресурса. Это может произойти практически при любом предположении, что ресурс локальной машины может быть монополизирован. Такие вещи, как конфигурационные файлы, временные файлы и т. Д., Все должны предполагать, что другие пользователи могут дурачиться в той же области и иметь области машины / приложения и пользовательские области для настроек.

Эту проблему нелегко решить с помощью VB6, поскольку она является внутренней по отношению к сторонним подсистемам. Вероятно, вы увидите ту же проблему в стороннем приложении, работающем в отдельных сеансах терминального сервера, и именно поэтому у первых пользователей терминальных служб было много трудностей со многими типами приложений. Мы были активными пользователями Citrix, и были приложения, которые вы просто не запускали на Citrix в некоторых ранних версиях. Даже приложения с хорошим поведением часто приходится устанавливать особым образом в зависимости от того, что рекомендует Citrix, Microsoft или поставщик.