При поставках заказчику собственного программного обеспечения наблюдалась ситуация: иногда при непредвиденном изъятие конвертера USB/RS485 из системы Windows XP (часто ситуация возникает из-за человеческого фактора, а также м.также возникнуть в результате воздействия сильной электромагнитной помехи при коммутациях со стороны высоковольтной линии 6кВ на конвертер при непосредственной близости обоих) происходит зависание программного обеспечения (разработчик данного ПО не я). По словам программиста зависание происходит где-то в api-шных функциях винды. При этом программа не отзывается и никаким образом не убивается, только перезагрузка помогает, хотя винда остается работоспособной,
Если какие-либо способы решить данную проблему при возникновении описанной выше проблемы.
Заранее большое спасибо.

решение может быть только одно - не использовать венду. у клиента случайно не N-ядерник ? венда имеет проблемы на N ядерных системах - так называемые race conditions между различными компонентами. как вариант, можно попробовать оставить одно ядро, путем замены hal.

Так сейчас везде N-ядерные системы - мы заказчику поставляем ноут с нашим ПО

А на чем конвертер сделан ? Не FTDI часом ?

Обычно используем I-7561 от ICPDAS

Блин, я уехал от заказчика, и у него начались аналогичные проблемы. Ищу на что бы спрыгнуть на другом чипе. FTDI неизолированный, к-й я вожу за собой не сбойнул ни разу, поэтому ищу промышленные изолированные на замену. Опять же, Пролифик со старыми дровами БСОДы выдавал регулярно, с новыми не выдает, но пропадание связи (а теперь и подвисание ПК) случается регулярно. Давайте поделимся проблемами - может, совместными усилиями поборем.

Если есть ХОРОШИЙ контакт с программистом, то можно из ситуации выкрутиться. Надо мониторить события PnP в винде. Может даже прийдется ставить программный Hook. После срабатывания Hook проверять, наш ли порт отвалился и заканчивать принудительно последнюю операцию и осовбождать порт. Проблема в том, что надо иметь исходники компонента, через который коммуникация с портом идет (никто же обычно не работает с портом через API) а применяют сторонние модуля, вот его прийдется править.

Не помогает. Освобождения порта не хватает - надо УСБ перевтыкать. Грустно.

Мы работатаем на уровне api-ных функций - юзаем их в C#. Хук то посадать можно - иногда он помогает, но вот если в момент выпадания конвертера программа обращается к апишными функциям, то происходит где-то зависание в этой апишной функции

Оказался глючный экземпляр конвертера. На столе без подключенной линии выдает дикие таймауты. Но вопрос "что использовать для уверенной работы" остается.

Вы далеко не первый с такой проблемой.
На данный момент решения нет. Самое разнообразное usb оборудование с той или иной периодичностью подвисает или отваливается. Проблема софтверно не лечится, так как для развешивания обязательно нужно переткнуть usb устройство.
Хотите уверенно работать - не используйте usb! Вот ethernet например вполне надежно работает, гальваническую развязку имеет по определению и его никто пока не объявил "устаревшим".

было такое с изолированным программатором АВР910 на СР2102 и длинным 5-метровым кабелем (мертво вис USB при включении/выключении питания программируемой платы, программа не снималась из диспетчера задач).
проблема решилась заменой кабеля на более качественный (толстый с хорошей экранировкой) и подключением прямо на задний разъем мат.платы (сначала подключились на переднюю панель компа)
перетыкание не помогало, программа продолжала висеть, СОМ-порт был занят. помогала только полная перезагрузка

А может дело в драйвере на шнурок

Мы после долгих и тщательных разбирательств пришли к тому же выводу. Т.е. проблему у некоторых драйверов и микросхем есть, но есть дырка и в самих виндовых драйверах. Если помеха приходит в "неудачный" момент (или отключение), USB отваливаются навсегда и никакие переделки в драйверах от этого не спасают. Где-то они забыли предусмотреть отсутствие ответа с таймаутом.

А с разными переходниками USB-COM - это отдельный вопрос. Там похоже еще и драйвер так раскорячен, что до синего экрана доходит. Но это похоже уже проблема драйвера.

Лучше использовать дэвайс для работы с RS 232 по Ethernet. 2 года использую, пока ни каких проблем не было.

А со стороны компьютера что за софт в этом случае используется? Чтобы это порт выглядил как обычный со всеми стандартными API наворотами, ведь прикладной софт никто переписывать небудет. И как тогда выглядит протокол по эзернету, чтобы в будущем обеспечивать совместимость?

Со стороны компьютера устанавливается софт, создаются виртуальные COM-порты и все прекрасно работает. Эти порты выглядят как обычные, со всеми стандартными API наворотами.
В общем это порт-сервер EDG-4508+ или там EDG-4516 разница лишь колличестве портов.
http://www.advantech.com/

Кроме XPort какие еще есть? И как они по деньгам сравнительно с УСБшными? И софт их не глючный ли?

что такое XPort? или что вы имели введу?

XPort. Навскидку еще Moxa NPort вспомнил.

Я решал эту проблему, в некоторых случаях спасает рестарт usb хаба в помощью утилиты DevCon, или в коде с помощью SetupAPI.DLL

Помехи наводил так, брал электрошокер и трещал около usb-кабеля, и usb зависал.

Сказал что в некоторых случаях по тому что, когда работала программа Field Bus Analyzer, и я ребутил usb с помощью DevCon все оживало. Но когда скажем я конектился своей программой или гипертерминалом, все подвисало на смерть, спасала только перезагрузка компа.

Видимо гипертерминал как и я, использовали виндовые функции: WriteFile, ReadFile (соответственно виндовые драйверы для доступа к COM-порту), а Field Bus Analyzer наверно использует другие драйверы...