SerialPort.Close() problem - can't shut down the application with the taskmanager!
This is a major issue - I use a serial port in an application here and I poll the status of the attached device by opening and then closing the port again.
If the device fails, SOMETIMES the SerialPort.Close() - method NEVER returns and this is really a show stopper.
The worst thing is that even shutting down the application using the taskmanager fails, it doesn't work (or it is forbidden, by chance).
The attached device is a POS printer (USB) which simulates COM3, it's an Epson TM-T88IV (a very good model, btw).
Does anyone of you have experience with that?
5 ответов
Не рекомендуется многократно открывать и закрывать порт. Проверьте раздел «Примечания» в статье библиотеки MSDN для SerialPort.Close (). Есть фоновый поток, который необходимо завершить, прежде чем порт можно будет снова открыть, что требует времени. Количество времени непредсказуемо.
Метод Close () может легко заблокироваться, если обработчик событий DataReceived в данный момент запущен. Наиболее типичный способ выйти из тупика - вызвать Control.Invoke () в обработчике событий. Убедитесь, что в обработчике событий не используется код, который блокирует или требует переключения контекста потока. Использование BeginInvoke () - это нормально.
Невозможность убить программу вызвана проблемой в драйвере устройства последовательного порта. Запустите Taskmgr.exe, вкладку «Процесс», «Просмотр» + «Выбрать столбцы» и отметьте «Ручки». Если после завершения программы вы видите столбец Handles, показывающий 1, значит, драйвер последовательного порта зависает от запроса ввода-вывода, который не завершен.Процесс не может завершиться, пока не будут завершены все его потоки режима ядра.
Вы мало что можете поделать с этой конкретной проблемой, кроме как надеяться на обновление драйвера или переход к другому поставщику. В частности, эмуляторы последовательного порта USB печально известны плохими драйверами устройств. Вы избавитесь от такого смутьяна, вынув его со стоянки и несколько раз наехав на него своей машиной.
Другой типичной проблемой эмуляторов USB является то, что их очень легко отключить во время использования. Это работает примерно так же, как выдергивание флеш-накопителя из гнезда во время записи на него Windows. Это также был бы хороший способ заставить драйвер устройства зависнуть. Версии .NET до версии 4.0 страдают от сердечного приступа в фоновом потоке, когда устройство внезапно исчезает. За исключением обновления, небольшая табличка рядом с разъемом с надписью «Не отключайте во время использования!» это практический обходной путь. Они все равно будут, но через пару раз им это надоест.
Черт, в противном случае существует значок «Безопасное извлечение оборудования» на панели задач. Вы получите твердое «Не делай этого!» ошибка, пока ваша программа использует порт. Но, конечно же, операционная система бессильна заставить пользователей использовать ее. У Apple патент на метод, позволяющий сделать его отказоустойчивым, обнаруживая пальцы пользователя на устройстве :)
До .Net 4.0 многое могло пойти не так с USB для устройств SerialPort (сбой программы / системы и т. Д.). Ошибки было легко проверить, вытащив USB-адаптер при активном порте.
Недавно я провел несколько тестов с использованием .Net 4.0, и это исправлено (определенно улучшено) ??? Тест был простым приемом / передачей через USB-порт SerialPort с обратной связью и подключением USB-адаптера во время использования. Моя программа не вылетела, и я смог повторно открыть порт! Это серьезное улучшение.
Хотя иногда возникает проблема, что метод SerialPort.Close заходит в тупик, это не должно помешать диспетчеру задач убить ваш процесс. Если вы не можете убить свой процесс, это почти наверняка связано с ошибкой в драйвере последовательного порта USB. К сожалению, ваши варианты, скорее всего, следующие:
- не опрашивать состояние устройства
- заставить производителя исправить ошибку
- обойти проблему, придумав способ опроса состояния устройства без доступа к последовательному порту
- обойти проблему, получив доступ к устройству другим способом (возможно, прямым манипулированием USB)
Вот ссылка с множество других ссылок на эту проблему и (потенциальные) решения:
Как насчет использования потока BackGround для опроса устройства, чтобы он не мешал вашему приложению выйти?