Тест драйвера com порт недоступен

Обновлено: 22.01.2025

📝 Обратился клиент с вопросом: « Помогите, не работает сканер штрихкодов ». Смотрим — 1С запускается в сеансе удаленного рабочего стола, сканер ШХ подключен локально на ПК кассира. Такие вводные.

Об использовании com-портов и сканеров штрихкода при запуске 1С в терминальном режиме Об использовании com-портов и сканеров штрихкода при запуске 1С в терминальном режиме

Общие рекомендации

❓ Что проверить перед началом работы:

1. В каком режиме настроен ваш сканер ШХ — как HID-клавиатура (USB-устройство ввода) или эмуляции com-порта. Проверьте корректность работы сканера до подключения к удаленному серверу.

Устройство должно быть доступным, т. е. не занятым никакими другими приложениями. Если используете com-порт, зафиксируйте номер ( например, COM3 ) — через « Диспетчер устройств ».

2. Параметры RDP на клиенте — в приложении « Подключение к удаленному рабочему столу » в «Локальные ресурсы» должна быть проставлена галка «Порты».

На сервере, соответственно, конфигурация узла сеансов должна разрешать перенаправление com-портов для пользователя. Проверить в сеансе из командной строки:

, где X — номер порта.

Результат успешного выполнения — показ параметров порта (состояния устройства). Если возвращается код « Недопустимое имя устройства » — ошибка в номере или успешности перенаправления.

Важно : если на сервере, физически или виртуально уже имеется com-порт к указанным номером из п. 1, то перенаправления не будет. В этом случае — поменяйте номер порта на клиенте на любой свободный (следующий), а только потом выполняйте соединение.

Пример (com1 — есть «контакт», com2 — ошибка)

3. Установка драйвера (на сервере)

В комплекте с драйверами, как правило, идет приложение для теста сканера ШХ.

Найдите, выполните проверку связи — запишите, что возвращается после обмена, как запрограммирован сканер ( префикс, суффикс ).

4. Добавление устройства в 1С

✅ В итоге: загвоздка была в настройках 1С, точнее в свойствах самого устройства из «Подключаемое оборудование» — не правильно настроено поле «Суффикс». Как только поставили верный код (нашли через тест драйвера) — сканер заработал.

⚡ Подписывайтесь на канал или задавайте вопрос на сайте — постараемся помочь всеми техническими силами. Безопасной и производительной работы в Windows и 1С.

Именно! Ключевое слово – виртуализация.
Собственно, весь дальнейший текст не особо интересен, разве только в качестве скучного детектива.

Костыль оказался до смешного прост, но разбор полётов был капздец, опишу только основное. Всё не мог понять, почему раньше работало, а потом перестало. Через несколько дней позвонили с другой конторы, с этой же проблемой. Связался с ещё парой клиентов, у которых всё работает, и так уж оказалось, что у них отключены обновления системы, и я подумал, что прилетело какое-то обновление, которое всё сломало. Потратил много времени на сравнение протоколов обновлений, напрасно. Потом плюнул и взялся за Procmon. Колупания в его логах то ещё развлечение, но именно оно вывело на верное направление.

Проверял под Win7/32. Увидел следующее. Настроечная прога от Штрих-М «Тест драйвера ФР» при обычном запуске (не от админа) читает и пишет параметры соединения в ветку
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\ShtrihM
Есть фоксовая программа, скомпилированная в exe, она создаёт COM-объект драйвера кассы и работает с ним. Если её запустить из среды VFP ("vfp9.exe прога.exe"), этот объект читает параметры из этой же ветки реестра, поэтому связь с кассой работает. А вот если запустить этот же exe-шник «в чистом виде» (не из-под VFP), то созданный объект пытается читать параметры из
HKEY_LOCAL_MACHINE\SOFTWARE\ShtrihM
ничего там не находит и, видимо, использует параметры по умолчанию - COM1 и прочее. И, разумеется, потом отвечает, что COM-порт недоступен либо нет связи.

Сперва сваял переливку из HKCU в HKLM. А потом обнаружил, что просто напросто нужно удалить ключ из HKCU\…\VirtualStore и этот «Тест драйвера ФР» запускать от админа, тогда и он будет сохранять в HKLM, и потом всё подхватывается. Чтоб потом не ошибиться можно в свойствах Теста (не своей программы) поставить галку «всегда от админа». Собственно, хэпиенд.

Это всё понятно и общеизвестно, просто за давностью забылось. Вопрос-то в том, почему у меня раньше работало, а тут перестало. И тут дурацкое стечение обстоятельств.

Виртуализация не включается: для 64-битных процессов; скрытых процессов (сервисов); ещё в некоторых случаях; и, в данном случае главное, для процессов, у которых в манифесте указан параметр requestedExecutionLevel .

Так вот, где-то в сентябре звонит мне одна контора. У них есть пара удалённых работников, которые работают по RDP. Возникли проблемы: прога при запуске пишет, что уже запущена и её рабочая папка занята, к тому же не видит проброшенные принтеры. Давай разбираться. У меня прога при запуске определяет факт работы под RDP и для хранения всяких рабочих и временных файлов использует отдельные папки для разных пользователей. Определяет это по GetEnv("SessionName") (вообще-то, можно через winapi, но зачем). А тут смотрю, программа эту переменную вообще не видит, зато у неё появились какие-то __APPCOMPAT_MANIFEST="" и __COMPAT_LAYER="VistaSetup RunAsAdmin". Увидев слово manifest, стал играться с ним – правил, удалял, вшивал в exe… А потом обнаружил, что на том компьютере кто-то умудрился в ярлыке моей проги установить «запуск от админа для всех пользователей». Снял эту галку, и всё заработало как надо. А о том, что что-то крутил с манифестом, на радостях забыл.

А, как оказалось, Windows определяет, для Висты написана прога или раньше, по наличию requestedExecutionLevel только во вшитом в exe манифесте, а на файл прога.exe.manifest для этого не смотрит. Вот и получается, что раньше, пока внутри exe-файла манифеста не было, система считала программу старой и включала для неё виртуализацию реестра, несмотря на наличие requestedExecutionLevel во внешнем файле. Поэтому возвращала для объекта, созданного в моей проге, параметры из того же места, куда пишет Штриховская прога, и всё работало. А когда я, почти случайно, воткнул свой манифест в exe-файл, система перестала включать для него виртуализацию, поэтому параметры Штриха не находились. Эту «экспериментальную» версию успели скачать несколько клиентов, двое из них используют кассы Штрих под Win7 и Win10, у них и возникла проблема.

Ну а при запуске из-под VFP работало, потому что первичным процессом являлся vfp9.exe, в манифесте которого параметр requestedExecutionLevel отсутствует, поэтому виртуалазация включалась, и всё работало.
Такая вот песнь песней.
Спасибо всем принявшим участие! И всем, дочитавшим до этого места

Igor Korolyov
Ну и как всегда - если ничего не помогает, может стоит обратиться в техсаппорт - подскажут как собрать детальные логи, а может это вообще known issue

Да там такой саппорт, что… только б ещё больше времени потратил. Почитал их полудохлый форум, но глухо.

COM-порты - общие компоненты диспетчера устройств. Пользователи Windows могут легко их увидеть, открыв диспетчер устройств. Однако могут возникнуть проблемы, из-за которых COM-порты будут потеряны из диспетчера устройств. Если вы столкнулись с этой проблемой, прочтите методы, упомянутые ниже, чтобы попытаться решить проблему самостоятельно.

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

Как получить доступ к портам диспетчера устройств Windows 10?

Щелкните правой кнопкой мыши на Этот ПК значок на рабочем столе.
выберите Управлять из контекстного меню.
Выбрать Диспетчер устройств в Системных инструментах. (Вы также можете нажать Start + X, чтобы выбрать Диспетчер устройств .)
выберите Посмотреть из строки меню.
выберите Показать скрытые устройства из подменю.
Найдите Порты (COM и LPT) из списка на правой панели.
Разверните его, чтобы найти Коммуникационный порт (COM) .

COM-порты отсутствуют в диспетчере устройств

Однако многие люди говорят, что не могут найти порты в диспетчере устройств и им отчаянно нужно решение этой проблемы.

COM-порты, не отображаемые в диспетчере устройств: все случаи

Первый: Com-порт отсутствует / опция портов недоступна в диспетчере устройств.

Два: в диспетчере устройств не отображаются порты (даже скрытые) Win 7 Pro 64 бит.

Я не могу заставить работать внешний модем (даже если он отображается в окне устройств и принтеров. Я также не могу заставить работать конвертер USB-последовательного порта. Было бы полезно, если бы у меня была информация из окна диспетчера устройств, но ничего не отображается, хотя я включил отображение скрытых устройств. Есть идеи? Спасибо. - спросил Пол Саке на форуме Microsoft.

Три: COM-ПОРТ исчез в диспетчере устройств.

Когда я открыл диспетчер устройств в то время, я обнаружил, что параметр COM-порта портативных устройств исчез из диспетчера устройств. Что мне нужно сделать, чтобы решить эту проблему? - сказал SAY014 на форуме HP.

Итак, как решить проблему и найти COM-порты Windows 10? Продолжайте читать!

Как добавить COM-порт в диспетчер устройств

Некоторые пользователи жаловались, что их COM-порты Widows 10 исчезли из диспетчера устройств после того, как они обновили свои платформы Windows. Какой бы ни была причина, пользователи в первую очередь заботятся о том, как восстановить недостающие COM-порты. Об этом я и расскажу в этом разделе.

Метод 1. Показать скрытые устройства.

Как я уже упоминал в начале этой статьи, пользователи не могут видеть COM-порты напрямую. Вместо этого им нужно открыть Диспетчер устройств -> выбрать Посмотреть вкладка -> выбрать Показать скрытые устройства . После этого они увидят Порты (COM и LPT) вариант, и им нужно только расширить его до COM-портов плавников.

Способ 2: добавить COM-порты вручную.

Откройте Диспетчер устройств на своем компьютере с Windows 10.
Нажми на Действие вариант из строки меню.
выберите Добавить устаревшее оборудование из подменю, чтобы открыть окно «Добавить оборудование».
Нажми на следующий кнопку, чтобы двигаться дальше.
Проверьте Установите оборудование, которое я выбираю вручную из списка (Дополнительно) и нажмите следующий .
Выбрать Порты (COM и LPT) из данного списка и нажмите следующий кнопка.
выберите Стандартные типы портов вариант или производитель портов; затем щелкните следующий .
Нажми на Конец кнопку для завершения.

Способ 3: обновите драйверы материнской платы.

Если драйверы материнской платы слишком устарели, это также приведет к отсутствию COM-портов в диспетчере устройств. Поэтому вам рекомендуется обновить драйверы материнской платы вручную и посмотреть, работает ли это.

Тема оказывается очень востребована, так как столько заходов на наш сайт по запросу Атол порт занят просто поражает.

В период окончательного перехода на драйвер Атола 10 появилась милая проблема:

Иногда после установки драйвера Атол 10 в системе Windows появляются 2 Com порта

И вот при связи из программы 10 драйвера : один порт занят , а по другому Нет Связи.

Примечание : обратите внимание atol-usbcom_proxy1 - это порт, по которому мы управляем кассовым аппаратом.

Примечание : обратите внимание atol-usbcom_proxy2 - это порт, по которому кассовый аппарат посылает чеки в интернет.

Полная переустановка драйверов и перезагрузка - не помогает.
Сюда же можно отнести ситуацию , когда касса печатает на тесте связи с ОФД - приложение EoU: не найдено
Все это связано с неправильной настройкой сервиса EoU.

EoU - это Ethernet Over Usb

Это специальная программа (сервис в ОС Windows) , которая запускается со стартом ОС и висит постоянно , обеспечивает передачу данных из USB VCOM в интернет. Так вот эта прога может захватить не тот COM порт, в Windows это всегда делается монопольно, т.е. другая программа например Атол Драйвер 10 уже не может его открыть.

Пикантность ситуации в том , что раньше в драйвере ДТО 8 была утилита DTOIntergrator, которая настраивала EoU сервис , но в драйвере 10 ее по непонятным причинам теперь нет.

Чтобы посмотреть настройки EoU пока есть два способа

Первый - качаем опять старые драйвера ДТО8 (например 8.16 , можно устанавливать параллельно с ДТО 10) и устанавливаем только EoU:

И теперь у нас появляется утилита DTOIntergrator

Запускаем ее и видим , что действительно порт занят сервисом :

Надо его поменять на другой порт ( у нас например 88), перезапустить сервис и все заработает нормально.

Есть нюанс , по которому можно заметить какая EoU установлена на ПК : смотрим сервис и видим отображаемое имя EoU - это EoU из драйвера ДТО 8.

В версии из ДТО 10 по другому будет:

Второй способ - как изменить настройки порта EoU

Чтобы изменения вступили в силу надо сначала остановить сервис EoU, изменить файл settings.xml , сохранить, и потом запустить сервис.

Теперь дополнительно некоторые нюансы : устанавливаем заново драйвера , кстати их 2 варианта под разрядность операционной системы 32 или 64 .
Допустим выбираем KKT10-10.3.1-windows64-setup:

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

Кстати USB порты отличаются : смотрите например сведения Строгое имя узла

Если поизучать установочный inf файл драйверов USB Атола (у меня oem95.inf) см. каталоге C:Windowsinf , то в принципе понятно , что упоминания о EoU там нет и следовательно это утилита устанавливается отдельно от драйверов USB.

Надо отметить , что у Атола есть некая прога , которую можно отдельно скачать с со страницы загрузки. Что это за вариант EoU непонятно, но там куча версий этой программы.

Почему Атол до сих пор не исправил этот глюк с захватом не того порта при установке EoU - для меня не понятно (наверное так интересней жить).

Читайте также: