1с ошибка инициализации netbios
Сетка
20+ клиентов на win xp(SP2,SP3)
несколько серверов
внутренний домен
у серверов статичные ip у клиентов динамические
\\s1: скажем так "основной"
OS: Win 2003
на нем: AD, File-serv, DNS(1), DHCP, там же сервер терминалов и WINS(теперь)
боевые функции его 2 - Файловое хранилище и основной DC.
\\s2:(дублирующий)
OS: Win 2003
на нем: AD,DNS(2), File-srv, Term-srv и теперь WINS
его боевая функция - Сервер терминалов и он же Сервер лицензирования всех остальных term-srv
теперь дилемма:
в секе переодически отваливается резолвинг NB-имен.
т.е. некоторые сервера перестают пускать клиентов по \\имя_сервера но продолжают пускать по \\ip
сетка разнесена на 2 здания на несколько этажей, объединена простенькими Dlink'овскими свичами. И вот никакой системы в этих сбоях я так и не нашел. Ресурсы S1, которые запрашивают все 20+ клиентов каждый день с утра до вечера по \\ip доступны всегда, а по \\имени к нему переодически кто-то не может достучаться. При чем есть проблемная комната, с тремя компами где такая проблема возникает каждый божий день, но после нескольких перезагрузок компьютера-клиента проходит(не всегда, может просто со временем) и есть показательная машина - это s2 с которой ресурсы \\s1 не доступны вообще(последние пару недель), ресурсы клиентов по \\имя так же не доступны, ресурсы некоторых других серверов бывает что и открываются по \\имя.
с s3 и с нескольких клиентов \\s1 доступен ВСЕГДА, т.е. ошибка такая никогда не возникала. В сетевом окружении все компьютеры видны друг другу ВСЕГДА.
Переставлять системы - не вариант.
все действия класса "потереть тряпочкой" попробовал - не помогает
На S1 перставил вчера DNS, снес WINS, не помогло
потом поставил DNS на S2, поставил WINS на оба s1 и s2
DNS под виндой стаивл первый раз в жизни, есть там для меня неявные моменты, и вообще странности. В частности есть там 2 зоны domain, domain.local и нечто загадочное с именем _msdcs.domain.local, что ставится автоматически. Обратная зона стала называться 10.0.0.x Subnet (до переустановки называлась in-adr.arpa). В общем не суть, проблем это не решило.
Проблема для меня важная и решить ее нужно. Сеть мне досталась в наследство, когда стала появляться ошибка не понятно.
Куда рыть?
Уверены, что "сервера перестают пускать клиентов"? Или же всё-таки клиенты перестают находить сервера по NeBIOS-имени?
Добавьте в список рассылаемых по DHCP настроек параметр 046 WINS/NBT Node Type и назначьте ему значение 0x2. На всех серверах явно назначьте это же через реестр в[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters]
"NodeType"=dword:00000002
Перезагрузите все проблемные компьютеры. После старта они получат новые настройки. Выполните те же команды. Пробуйте. Как только проявится проблема, сразу тут же на клиенте выполните nbtstat -A . Буква A именно большая! Ну, и с остальными параметрами команды можете заодно поэкспериментировать с умом.
Когда всё наладится: если WINS-сервер в сети есть, можно и оставить 0x2, а для более гибкой настройки клиентских машин можно поменять на 0x8.
Справка
1 - b-узел [широковещательный узел] (broadcasts)
2 - p-узел [одноранговый узел] (point-to-point name queries to a WINS server)
4 - m-узел [смешанный узел] (broadcast then query name server)
8 - h-узел [гибридный узел] (query name server, then broadcast)
Перед тем, как рассказывать о чем либо в этой статье, внесем некоторые оговорки:
1) не все перечисленные глюки можно на самом деле считать глюками – довольно часто термином Глюк называют ситуации, в которых программа ведет себя не так, как предполагает пользователь,но проблема тут не в программе,а в представлении пользователя. В этой статье такие ситуации мы также будем называть глюками;
2) не все описанные в статье глюки происходят из-за ошибок в программных продуктах 1С – просто они происходят именно тогда, когда используется 1С;
3) не все описанные в статье глюки относятся к сети, но большинство из них наиболее ярко проявляются именно при работе с сетью;
4) некоторые из глюков вообще не относятся к 1С;
5) все изложенная информация основана на личном опыте, а не взята из технических рассылок компании 1С
Введение
Для начала нужно научиться различать неполадки, которые возникают с опознаванием и считыванием данных с ключа защиты NetHASP, от неполадок, которые связаны непосредственно с работой 1С. Такое распределение неполадок абсолютно оправдано, ведь доступ к NetHASP осуществляется только при запуске программ 1С. Когда ключ успешно распознан и программы декодированы, ключ уже не нужен. Если вы не верите, то запустите 1С, а потом выньте ключ. Как видите, программа продолжает работу безо всяких ошибок до того момента, пока вы не выйдете из нее. Поэтому мы будет различать глюки, возникающие при опознавании ключа, от глюков, которые возникают во время работы с 1С.
1) Инициализация сервера защиты
Наверное, в этот момент совершается большинство всех глюков, связанных с работой программ от 1С. Начнем, пожалуй, с самых странных глюков
Если во время установки ключа защиты на сервера по ОС Windows NT, вы будете совершать все рекомендации, прописанные в документации, и установите сервер NetHasp server как сервис, тогда вас может ждать большое удивление: при перезагрузке NT постоянно будет показывать синий экран смерти, также известный как BSOD. Тут остается только заново переустанавливать NT Server. Мы пытались узнать, как версия релиза NetHasp влияет на появление BSOD, но так этого и не поняли; единственным из релизов, при котором таких проблем не возникало, был 13-й. Но зато мы поняли причину ошибок – SAP Support, к которому, очевидно, NetHaspServer относится не очнь хорошо. Нужно лишь исключить SAP Support из сетевых протоколов, и BSOD больше не появится. Конечно, можно не устанавливать NetHasp Server в качестве сервиса, и запускать его при загрузке NT любым из возможных способов – но в этом случае SAP Support будет продолжать конфликтовать с NetHasp Server; иногда сервер NetHasp не распознает NetBios, даже если он подключен.
Рассмотрим следующий глюк. Его сложно назвать абсолютно сетевым глюком, но, впрочем, появляется он только в сетевых версиях, и именно тогда, когда доступ к ключу проводится посредством NetHasp Server.
Если используются некачественные motherboard’ы, с ними могут не работать многие ключи.
2) Принтеры
Если мы уже заговорили о портах LPT, то нужно упомянуть также лазерные принтеры, а особенно такого их представителя, как HP LaserJet 6L. Они отличаются тем, что очень быстро уменьшают напряжение на ключе, делая его этим непригодным для работы. Здесь выход очевиден – установить дополнительный порт LPT. Часто принтер просто садит порт, и работать на таком порту может всего один ключ, на несколько – не хватит мощности. Есть даже такие принтеры, которые моментально снимают все напряжение ключа в том случае, если выключить питание принтера после того, как будет выключено питание компьютера. Особенно это актуально для многофункциональных устройств, которые совмещают в себе принтер, ксерокс, факс, сканер. Правда, не все принтеры так плохо влияют на ключи.
Отдельное место тут занимают принтеры компании LexMark, а точнее не так принтеры, как написанное для них программное обеспечение, то есть не что иное, как драйвера. Создается впечатление, что их писали совсем не программисты, а агрессивно настроенные люди, которые плохо относятся ко всем сетевым принтерам от других производителей. Рассмотрим такую ситуацию: на вашем компьютере есть драйвер принтера Lexmark, при этом компьютер подключен по сети, и однажды вы установили этот принтер как такой, который доступен другим пользователям сети; затем вы отключаете принтер, не удаляя драйвер. После этого, как бы вы не старались сделать сетевую печать для принтера от других производителей, если их подключить туда, где раньше был установлен Lexmark – не выйдет, и ни один из пользователей сети не сможет ничего напечатать. Даже если удалить драйвера от Lexmark, это помогает не всегда – иногда даже приходится переустанавливать Windows. А теперь представьте, как будет работать ключ NetHasp, если включить его в порт, над которым овладел драйвер Lexmark; нормальных драйверов для Lexmark пока не найдено..
И еще о работе с принтерами. Бывают случаи, когда несколько компьютеров, подключенных к одному хабу, начинают медленно работать; связь через витую пару 10Мбит/с. Во время просмотра справочника эти компьютеры зависали на несколько секунд, при этом причины таких зависаний были сначала совсем непонятны. Бывает, что в этом виноваты принтеры, драйвера для которых подобраны неправильно, то есть, например, драйвера для более старой ОС, а установлены они на более молодую версию Windows.
3) TCP/IP
Конечно, ничего плохого в протоколе TCP/IP нет. Но для систем, где используются программы от 1С, он не очень подходит. Конечно, в каждой системе могут нормально сосуществовать несколько протоколов, и среди них может быть и TCP/IP. Но системы с 1С могут спокойно работать нас IPX/SPX, или же на NetBios. Программы от 1С, которые работают на TCP/IP, функционируют вполне нормально, но не так быстро, как могли бы. Тем более, есть определенные нюансы, связанные с работой NetHaspServer на протоколе TCP/IP. По сути, главная задача TCP/IP – обеспечивать маршрутизацию сложных сетей, но в локальных сетях из нескольких сегментов, NetHaspServer иногда с большим негодованием дает доступ к ключам программы, запущенным на других сегментах этой сети. В этом скорее всего виноват именно NetHaspServer, но ситуацию это не исправляет. Систематизировать глюки этого вида сложно.
TCP/IP имеет и другие не очень хорошие проявления при работе с 1С. Если протокол TCP/IP установлен, но еще не настроен на нескольких компьютеров в сети, программы 1С могут искать ключ минут 3-5, и в дальнейшем тормозить во время работы настолько, что нормально работать практически нельзя, точнее можно, но трудно. Торможение касается всей сети, а не только компьютеров, где установлены TCP/IP. Устранить такой глюк просто – снести TCP/IP на одном из компьютеров. Ситуация эта проявляется далеко не всегда, но бывает же.
4) NetBIOS, IPX/SPX и NetHASP
Мы решили наконец понять, что именно, то есть какие протоколы нужно иметь в сети, чтобы поиск ключей был максимально быстрым и надежным, а программы запускались моментально и не давали глюков. После нескольких экспериментов, у нас появились некоторые результаты. Мы уверены в нижесказанном не на 100%, но просто подаем интерпретацию результатов экспериментов:
Для одноранговых сетей под Windows95 наилучшим вариантом является NetBIOS, причем настоящий, а не эмулированный. Сеть работает вполне быстро, а протокол этот установить довольно легко. Недостатком в этом случае является только то, что протокол NetBIOS не маршрутизируется по сетям из многих сегментов,хотя для многих это важной роли не играет. Нерациональным использование NetBIOS на таких сетях будет только в том случае, если есть сетевой принтер наподобие JetDirect – он требует для работы только IPX/SPX.
Если в одноранговую сеть включены больше, чем 6-7 компьютеров, и все эти компьютеры должны иметь доступ к серверу, тут может быть побольше глюков. Ресурсы Windows95 на компьютере, который выступает как сервер, не позволяют ему заниматься больше, чем 5-6 экземплярами программы 1С:Торговаля или же 1С:Бухгалтерия, если они запущены на других компьютерах; заметим, что каждый экземпляр программы 1С открывает больше чем 200 файлов на дисках сервера. Как результат – запуск шестого или седьмого экземпляра программы от 1С проваливается. Конечно, можно установить выделенный сервер, но обычно в таких ситуациях на сервер устанавливают NT Workstation. Если уж так, что в этом случае наилучшим решением будет IPX/SPX, не включая поддержку SAP. Его работа не медленнее, чем NetBIOS. Бывает, что некоторые пытаются эмулировать NetBIOS на IPX – делать так не нужно, ведь будет торможение.
Вышеописанный вариант действий вполне подходит также для систем с выделенными серверами на ОС Windows NT Server
Если система находится под управлением выделенного сервера Novell NetWare 3,12 или 4,11, протокол IPX/SPX является наиболее оптимальным решением. Его использование дает хорошую скорость, как и надежность при поиске ключа; причем если использовать конфигурацию с двумя процессорами, скорость будет необычайно высокой. Только избегайте установки на рабочие станции клиента Novell, ведь глюков будет больше, чем можно было ожидать. Что бы там не говорили насчет Microsoft, клиент NetWare от этой компании работает довольно хорошо.
Если на вашей сети установлено несколько протоколов, запись в файл Autoexec.bat с текстом set nethaspprotocol=… будет определять только протокол, который используется при поиске ключа для сети. Но какой протокол будет выполнять действия программ 1С с файлами? Исследования показывают, что если на нескольких компьютерах сети установлены разные протоколы, и каждый из них выбирает тот протокол, который ему больше подходит – тут и появляются глюки. Поэтому лучше выбирать единый протокол.
5) Драйвера, совместимые с NE2000
Довольно часто во время установки сетевой карты на компьютеры под ОС Windows95 система лично определяет эту карту как NE2000-совместимую, и поэтому устанавливает соответствующий драйвер. Многим так называемым специалистам хватает и этого, либо они просто не ищут нормальных драйверов, ведь зачем лишнее время тратить. Но такая экономия времени на самом деле может обернуться множеством пресловутых глюков.
Да, если установить на сетевую карту NE2000-совместный драйвер, сеть может быть довольно работоспособной. Но если установить такой драйвер на современные карты, получается то же самое, что было бы если драйвера VGA установить на хорошую видеокарту – то есть использовать всю функциональность сети не выйдет. Сетевые карты содержат множество аппаратных функций, которые использует сетевое ядро Windows95 посредством драйверов этой карты. Если установлен родной драйвер, все функции используются как и должно быть, но если обходиться только NE2000-совместным драйвером, то он сможет распознать только некоторые из функций карты.
Около 70% всех случаев, когда программы 1С в сети работали неправильно, то есть не находили ключ, связаны с тем, что NE2000-совместимые драйвера используют вместо оригинальных, которые идут на дискетах или дисках. Особенно актуально это при установке драйверов на тот компьютер, где уже установлены ключи NetHasp
Метод исправления таких глюков вполне ясен: просто установить оригинальный драйвер, скачав его с Интернета или взяв с диска. Если вы замечаете глюки при сетевой работе 1С, и на некоторых компьютерах находите NE2000 – первое, с чего нужно начать, это установка оригинальных драйверов данного устройства.
Если хотите проверить разницу между NE-2000 совместимыми и оригинальными драйверами, сделайте следующее: вставьте карточку в сервер Novell NetWare, и установите сначала оригинальный, и потом NE-2000 драйвер; нужно брать драйвера для серверов с расширением lan. В обеих случаях включите программу Monitor и через нее посмотрите, какие функции есть у вашей сетевой карты.
6) Посторонние драйвера сетевых карт
В предыдущем разделе мы рассмотрели универсальные драйвера сетевых карт, которые ориентированы на работу с картами от разных производителей, и поэтому не позволяют использовать все возможности уникальных сетевых карт. Но бывает и обратное – оригинальные драйвера, созданные специально для этой звуковой карты, пытаются использовать ее возможности в полно объеме, а получаются от этого глюки. Чтобы объяснить этот пункт, расскажем реальную историю.
Была такая себе вполне нормальная сеть : 15-20 ПК, соединенных витой парой с сервером Novell NetWare 3,12. Тут понадобилось расширить эту сети, то есть добавить в нее 3 или 4 дополнительных компьютера. В каждый из них установили только что купленные сетевые карты на AMD и драйвера, взятые из дискет, которые шли вместе с картами. Все работало нормально, пока не присоединили 4-й компьютер. Когда на него начали устанавливать драйвера, то выяснилось, что на дискете кроме стандартного драйвера есть еще и так называемый турбо драйвер. Из файла Readme мы прочитали, что от применения этого драйвера скорость работы сети увеличится на 10-15 процентов. Решили попробовать, установили турбо драйвер, скорость передачи увеличилась. Было поздно, и на остальные компьютеры турбо драйвера устанавливать мы не захотели. Но с самого утра посыпались гневные отзывы – оказывается, работа системы от этого значительно замедлилась. Когда же мы выключили тот компьютер, где установлены турбо-драйвера, все начало работать с нормальной скоростью. После долгих изучений оказалось, что система работает быстрее только тогда, когда эти турбо драйвера поставлены на все компьютеры сети. Наверное, в файле Readme нужно было указать такое.
Так что не нужно гнать за новейшими достижениями, и внимательно следить за драйверами, которые вы устанавливаете.
7) 100-мегабитные сети
100-мегабитные сети также могут проявлять глюки при работе в 1С, кроме того, неясно, как эти глюки исправлять. Отношения именно к программам от 1С этот глюк не имеет, но все равно он значительно уменьшает скорость работы сети, поэтому нужно о нем знать. Проявляется он тогда, когда умный хаб 10/100, который может определять, какой канал какую скорость имеет, каскадирует хотя бы один обычный хаб на 10мегабит. Дополнительно к хабу 10/100 подключены несколько 10мегабитных станций, помимо 100мегабитных. Умный хаб иногда становится ну очень уж умным – путает 10мегабитные каналы со 100мегабитными, точнее считает некоторые 100мб линии 10мегабитными. Как результат – возрастает количество коллизий, от этого производительность страдает. Исправлять ситуацию можно кратковременными выключениями питания этого хаба, хотя бы на несколько секунд, иногда нужно также перегружать сервер. Вообще, такие глюка бывают редко, но если происходят, забирают много рабочего времени. Поэтому нужно либо полностью различать сегменты по 10 и по 100 мегабит, либо не использовать умные хабы, а вместо них настраивать комбинированных хабы с фиксированным количеством линий.
8) SQL-версии
Особых глюков, связанных с SQL не замечено. Разве что, можно посоветовать не забывать устанавливать NamedPipes во время установки MS SQL Server – если не установить, производительность будет не такой, какой может быть.
9) Некоторые рекомендации по глюкам больших сетей
Если вам приходится работать с большой сетью, то есть если в ней больше 20 компьютеров и выделенный сервер, то лучше всего будет использовать отдельный компьютер для установка на него ключей NetHASP. На сервер устанавливать их будет непрактично – ведь у него и так много занятий. Если сделать именно так, легче будет не только серверу, а и его администратору; этот компьютер с ключами может быть обычным ПК, не обязательно использовать для этого современные мощные компьютеры. Также можно организовать на этом ПК работу по приему и отправлению почты и факсов, или обслуживанию по DialUp, и другими функциями, которыми не хочется загружать сервер.
Также нежелательно ставить на сегмент сети больше чем 20 компьютеров, даже если на них не делают ничего важного. Трафик сегмента будет вызывать торможение сети.
Если есть возможность, используйте так называемый европейский метод разводки сети: кабели от каждого рабочего места ведут в определенную комнату. Для этого нужно больше кабелей, зато при эксплуатации это окупится.
Сетка
20+ клиентов на win xp(SP2,SP3)
несколько серверов
внутренний домен
у серверов статичные ip у клиентов динамические
\\s1: скажем так "основной"
OS: Win 2003
на нем: AD, File-serv, DNS(1), DHCP, там же сервер терминалов и WINS(теперь)
боевые функции его 2 - Файловое хранилище и основной DC.
\\s2:(дублирующий)
OS: Win 2003
на нем: AD,DNS(2), File-srv, Term-srv и теперь WINS
его боевая функция - Сервер терминалов и он же Сервер лицензирования всех остальных term-srv
теперь дилемма:
в секе переодически отваливается резолвинг NB-имен.
т.е. некоторые сервера перестают пускать клиентов по \\имя_сервера но продолжают пускать по \\ip
сетка разнесена на 2 здания на несколько этажей, объединена простенькими Dlink'овскими свичами. И вот никакой системы в этих сбоях я так и не нашел. Ресурсы S1, которые запрашивают все 20+ клиентов каждый день с утра до вечера по \\ip доступны всегда, а по \\имени к нему переодически кто-то не может достучаться. При чем есть проблемная комната, с тремя компами где такая проблема возникает каждый божий день, но после нескольких перезагрузок компьютера-клиента проходит(не всегда, может просто со временем) и есть показательная машина - это s2 с которой ресурсы \\s1 не доступны вообще(последние пару недель), ресурсы клиентов по \\имя так же не доступны, ресурсы некоторых других серверов бывает что и открываются по \\имя.
с s3 и с нескольких клиентов \\s1 доступен ВСЕГДА, т.е. ошибка такая никогда не возникала. В сетевом окружении все компьютеры видны друг другу ВСЕГДА.
Переставлять системы - не вариант.
все действия класса "потереть тряпочкой" попробовал - не помогает
На S1 перставил вчера DNS, снес WINS, не помогло
потом поставил DNS на S2, поставил WINS на оба s1 и s2
DNS под виндой стаивл первый раз в жизни, есть там для меня неявные моменты, и вообще странности. В частности есть там 2 зоны domain, domain.local и нечто загадочное с именем _msdcs.domain.local, что ставится автоматически. Обратная зона стала называться 10.0.0.x Subnet (до переустановки называлась in-adr.arpa). В общем не суть, проблем это не решило.
Проблема для меня важная и решить ее нужно. Сеть мне досталась в наследство, когда стала появляться ошибка не понятно.
Куда рыть?
Уверены, что "сервера перестают пускать клиентов"? Или же всё-таки клиенты перестают находить сервера по NeBIOS-имени?
Добавьте в список рассылаемых по DHCP настроек параметр 046 WINS/NBT Node Type и назначьте ему значение 0x2. На всех серверах явно назначьте это же через реестр в[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters]
"NodeType"=dword:00000002
Перезагрузите все проблемные компьютеры. После старта они получат новые настройки. Выполните те же команды. Пробуйте. Как только проявится проблема, сразу тут же на клиенте выполните nbtstat -A . Буква A именно большая! Ну, и с остальными параметрами команды можете заодно поэкспериментировать с умом.
Когда всё наладится: если WINS-сервер в сети есть, можно и оставить 0x2, а для более гибкой настройки клиентских машин можно поменять на 0x8.
Справка
1 - b-узел [широковещательный узел] (broadcasts)
2 - p-узел [одноранговый узел] (point-to-point name queries to a WINS server)
4 - m-узел [смешанный узел] (broadcast then query name server)
8 - h-узел [гибридный узел] (query name server, then broadcast)
Что такое ошибка NetBT 4311?
Всякий раз, когда вы видите ошибку NetBT 4311, вы видите, что инициализация не удалась, потому что устройство драйвера не может быть создано в Просмотрщик событий. Особого объяснения этому нет. Ошибка возникает только тогда, когда мы играем в игры, просматриваем Интернет или запускаем новые приложения. Он автоматически выключает или перезагружает ПК. Поскольку ошибка возникает при игре в тяжелые игры, мы можем связать ее с графическим драйвером.
Эта ошибка также может возникать, когда NetBIOS через TCP/IP (NetBT) пытается выполнить запрос, но терпит неудачу. Ошибка также может быть связана с неисправным сетевым адаптером. Он появляется даже при удалении сетевого адаптера. Всякий раз, когда возникает проблема с сетевым адаптером, вы видите ошибку NetBT 4311. Эта ошибка также связана со службой удаленного доступа.
- Отключить автоматический перезапуск
- Обновите все драйвера на вашем ПК
- Удалить недавно установленные сторонние программы
- Просканируйте свой компьютер на наличие вредоносных программ
- Используйте кнопку сброса сети
- Выполнить восстановление системы
Давайте углубимся в детали каждого метода.
1]Отключить автоматический перезапуск
Ошибка NetBT 4311 приводит к перезагрузке компьютера. Вам необходимо отключить автоматический перезапуск, чтобы применить исправления. Вам может не хватить времени на внедрение исправлений с ошибкой и перезапусками.
Чтобы отключить автоматический перезапуск,
- Ищи просмотреть расширенные настройки системы в меню Пуск и откройте его
- Он открывает окно «Свойства системы».
- Нажмите «Настройки» в разделе «Запуск и восстановление».
- Снимите флажок рядом с «Автоматический перезапуск» в разделе «Сбой системы».
- Нажмите OK, чтобы сохранить изменения
2]Обновите все драйверы на вашем ПК.
Поскольку ошибка связана с (неизвестным) драйвером, нам нужно убедиться, что все драйверы на ПК обновлены и работают нормально. Вам необходимо обновить все драйверы из диспетчера устройств.
Чтобы обновить драйверы из диспетчера устройств,
- Открыть команду «Выполнить»
- Тип devmgmt.msc и нажмите Enter
- Начните с аудиовходов и выходов, чтобы обновить каждый драйвер. Разверните один за другим и щелкните правой кнопкой мыши драйверы, выберите «Обновить драйвер» и следуйте указаниям мастера на экране.
- Повторяйте это, пока не закончите обновление всех драйверов на ПК.
Вы также можете обновить драйверы с помощью сторонних программ обновления драйверов, загрузить драйверы вручную с веб-сайта производителя и установить их или обновить их с помощью дополнительных обновлений Windows.
3]Удалить недавно установленные сторонние программы
Программа, которую вы недавно установили на свой компьютер, может быть причиной ошибки NetBT 4311. Вам необходимо удалить программу с помощью приложения «Настройки» или из меню «Пуск». Перезагрузите компьютер и проверьте, устранена ли ошибка.
4]Сканируйте свой компьютер на наличие вредоносных программ
Вам необходимо выполнить сканирование на наличие вредоносных программ или любых следов вирусов на вашем ПК с помощью антивирусной или антивирусной программы. Программное обеспечение обнаруживает изменения и находит вредоносное ПО, снижающее производительность вашего ПК, и исправляет его.
5]Используйте кнопку сброса сети
Откройте «Настройки Windows» и используйте кнопку «Сброс сети». Это удалит ваши сетевые адаптеры, а затем переустановит их, а для других сетевых компонентов вернутся их исходные настройки.
6]Выполните восстановление системы
Если ни одно из вышеперечисленных исправлений не работает, вам необходимо выполнить восстановление системы до того момента, когда ваш компьютер работал нормально без каких-либо проблем. Для выполнения восстановления системы.
- Поиск Создайте точку восстановления в меню Пуск и откройте его
- Перейдите на вкладку «Защита системы».
- Нажмите «Восстановление системы» и следуйте указаниям мастера на экране, чтобы восстановить компьютер.
Это различные способы, которые вы можете использовать для исправления ошибки NetBT 4311 на вашем ПК с Windows.
Пожалуйста, объясните почему, подскажите как и укажите на ошибки. Вот код подключения к Вашему API:
Соединение = Новый HTTPСоединение("dadata.ru". Новый ИнтернетПрокси,, Новый ЗащищенноеСоединениеOpenSSL);
Проблема в том, что со временем появляется ошибка вида:
То есть запросы могут проходить нормально и получать полноценный ответ, а потом через некоторое время начинают сыпаться ошибки. Подскажите куда смотреть и на что обратить внимание - хотим с Вами интегрироваться, но стабильности получить не удается. Тут явно что то с SSL - может явно как то Ваши сертификаты надо подсовывать 1С. но откуда их брать или. во общем помоги пожалуйста.
Ответ
Вот что удалось выяснить.
1. Документация 1С явно говорит о том, что сертификат клиента и сертификат удостоверяющего центра в простых случаях не требуются:
Создает защищенное соединение OpenSSL, использующего указанные источники клиентского сертификата и сертификатов удостоверяющих центров.
Если не указывается источник сертификатов удостоверяющих центров, то сертификат сервера не проверяется.
Если не указывается источник клиентского сертификата, то соединение возможно только с серверами, не требующими предоставления клиентского сертификата.
Это как раз наш случай: Дадата не требует клиентского сертификата.
2. Ваш код на моем тестовом сервере 1С работает без проблем.
3. Как вы пишете, у вас код тоже сначала работает, а ошибки начинают сыпаться через некоторое время.
В результате моя единственная гипотеза на сегодня — проблема в прокси-сервере или сетевых настройках, которые ваш сервер 1С использует для выхода в интернет. «Нечто» между сервером 1С и сервером Дадаты (ОС / прокси / маршрутизатор) через некоторое время перестает корректно обрабатывать исходящие соединения.
Читайте также: