Повторное открытие последовательного порта завершается неудачей, если не закрыто должным образом с помощью CloseHandle - PullRequest
Новая
       17

Повторное открытие последовательного порта завершается неудачей, если не закрыто должным образом с помощью CloseHandle

2 голосов
/ 01 июня 2010

Я работаю с USB-устройством в Windows, которое отображается как виртуальный последовательный порт. Я могу общаться с устройством, используя функции CreateFile и ReadFile, но в некоторых случаях мое приложение не вызывает CloseHandle (когда мое приложение в разработке падает). После этого все вызовы CreateFile завершаются ошибкой (ERROR_ACCESS_DENIED), и единственное решение - снова войти в мой компьютер. Есть ли способ принудительно закрыть открытую ручку (или снова открыть) программно?

Ответы [ 6 ]

2 голосов
/ 01 июня 2010

Я согласен с обоими предыдущими постами.

  1. Это не нормальная ситуация.
  2. Обычно помогает отключение USB-устройства.

Эта проблема связана с глюками в драйвере FTDI, который отвечает за реализацию виртуального COM-порта. С другой стороны, эти «глюки» связаны с различными неисправностями USB-устройств. (Конечно, это не оправдывает драйвер FTDI).

Кстати, есть некоторые другие известные проблемы с некоторыми драйверами FTDI:

  • Иногда вызов CloseHandle просто вешает вызывающий поток.
  • Иногда приложение также остается «видимым» в диспетчере задач, даже после его закрытия. Диспетчер задач не может завершить приложение, и отладчик не может быть присоединен к нему. Его EXE-файл заблокирован (не может быть удален).

Обычно отключение USB-устройства немедленно помогает в таких ситуациях. Драйвер FTDI, который, похоже, «чего-то ждет», пробуждается.

2 голосов
/ 01 июня 2010

Это конечно не нормально. Windows автоматически закрывает все дескрипторы, которые остаются открытыми после завершения процесса. Это должно быть недостатком в вашем драйвере USB-устройства, хотя трудно понять, как это могло испортить это. Те, которые эмулируют последовательные порты, однако, как известно, паршиво. Ну, ничего, что вы можете сделать, но надеяться на обновление драйвера от производителя. Или устройство другого производителя.

1 голос
/ 01 июня 2010

Есть ли вероятность того, что некоторые потоки или дочерние процессы вашей аварийной программы все еще работают и содержат копию дескриптора файла? Возможно, процесс отладки все еще открыт? Если так, то они могут держать устройство открытым. Я бы проверил диспетчер задач просто чтобы быть уверенным; в этом случае принудительное уничтожение оставшихся процессов может решить проблему.

0 голосов
/ 30 июня 2010

Может быть, вы можете добавить функцию Try catch close для вашего основного кода и вызвать CloseHandle в функции catch catch.Тогда, даже если программа сломается, будет вызван CloseHandle.

try {HANDLE hPort = NULL;hPort = CreateFile (...);// Вы кодируете ...

} catch (...) {if (hPort! = NULL) CloseHandle (hPort);}

0 голосов
/ 02 июня 2010

Еще одна вещь, которую вы не хотите делать, - это иметь открытый последовательный порт USB, и пользователь может подключить адаптер USB к последовательному порту. Эта ошибка была (есть?) Уже давно. Здесь был ответ на ошибку

"Опубликовано Microsoft 27.03.2009 в 16:03 Привет, Спасибо за сообщение об этой проблеме. Мы знаем об этой проблеме и исправили это для следующего основного выпуска .NET Framework.

Если у вас есть какие-либо вопросы, пожалуйста, активируйте эту проблему, и я отвечу как можно скорее. Спасибо, Ким Гамильтон Библиотеки базовых классов "

Не знаю, связаны ли проблемы. Microsoft Connect сообщает о нескольких последовательных ошибках USB.

0 голосов
/ 01 июня 2010

Попробуйте отключить устройство и снова подключить его. Иногда Windows нужно напомнить, что никто больше не подключен к этому порту.

...