← На главную

При публикации базы 1С на веб-сервере IIS многие разработчики и системные администраторы сталкиваются с ситуацией, когда веб-сервис успешно публикуется, база открывается в браузере и WSDL доступен, однако при отправке SOAP-запросов не происходит ответа от 1С. В журнале регистрации 1С мы видим записи об успешной авторизации, но на этом процесс останавливается. При этом в логах Windows часто фиксируется ошибка с кодом события 1000, указывающая на сбой приложения w3wp.exe с модулем ws.dll. Особенно часто такая проблема проявляется при запросах к методам, которые должны возвращать данные, тогда как простые методы (например, возвращающие одну строку) могут работать.

Давайте подробно разберем, какие шаги и настройки мы можем предпринять для диагностики и устранения данной проблемы.

1. Проверка и устранение несоответствия разрядности платформы 1С и пула приложений IIS

Одной из наиболее распространенных причин сбоев процесса w3wp.exe, являющегося рабочим процессом IIS, является несоответствие разрядности установленной платформы 1С и пула приложений IIS. Если мы используем 32-битную версию 1С (на что указывает путь установки C:\Program Files (x86)\1cv8), а IIS работает в 64-битном режиме, это может приводить к аварийному завершению работы. Мы рассмотрим два основных пути решения этой проблемы:

1. Разрешение 32-разрядных приложений для пула IIS:

Мы должны убедиться, что пул приложений, в котором опубликована наша база 1С, разрешает выполнение 32-разрядных приложений. Для этого нам необходимо выполнить следующие действия:

• Откроем Диспетчер служб IIS (Internet Information Services).
• В левой панели развернем узел сервера и выберем «Пулы приложений».
• Найдем пул приложений, который используется для публикации нашей базы 1С (часто это DefaultAppPool или пул с именем, соответствующим публикации).
• Правой кнопкой мыши щелкнем по нему и выберем «Дополнительные параметры».
• В открывшемся окне найдем параметр «Разрешены 32-разрядные приложения» (Enable 32-bit Applications) и установим его значение в True.
• Также рекомендуется проверить параметр «Версия среды .NET Framework» и установить его на v2.0 или «Без управляемого кода».
• Применим изменения и перезапустим пул приложений.
2. Установка 64-битной платформы 1С:

Если мы хотим, чтобы вся система работала в единой разрядности, логичным шагом будет установка 64-битной версии платформы 1С. Это позволит избежать потенциальных конфликтов разрядности. После установки новой платформы нам потребуется повторно опубликовать базу 1С на IIS, чтобы пути к файлам платформы (например, к wsisapi.dll) были обновлены.

2. Проверка прав доступа к каталогам и файлам

Недостаточные права доступа для учетной записи, под которой работает пул приложений IIS, являются еще одной очень частой причиной проблем. Если учетная запись не имеет необходимых разрешений на чтение, выполнение или запись в определенные каталоги, веб-сервис не сможет функционировать корректно. Мы должны убедиться, что у следующих групп и пользователей есть достаточные права:

1. Права для группы IIS_IUSRS и пользователя IUSR:
• Каталог платформы 1С: Предоставим полные права доступа к каталогу установки платформы 1С (например, C:\Program Files (x86)\1cv8 или C:\Program Files\1cv8). Это критически важно, так как IIS должен иметь доступ к файлам, таким как ws.dll, wsisapi.dll и другим компонентам платформы.
• Каталог сайтов IIS: Убедимся, что права предоставлены к каталогу C:\inetpub и всем его подкаталогам, если в них размещаются файлы публикации.
• Каталог публикации базы 1С: Обязательно предоставим полные права доступа к каталогу, куда была опубликована наша база 1С.
2. Разрешения NTFS для файла web.config:

В директории публикации базы 1С находится файл web.config, который содержит ключевые настройки для веб-сервиса. Мы должны убедиться, что у группы IIS_USERS есть права на чтение, выполнение, запись и изменение для этого файла. Это важно для корректной работы и возможных изменений конфигурации.

3. Публикация от имени администратора:

При первой публикации базы 1С на IIS всегда рекомендуется выполнять эту операцию из конфигуратора 1С, запущенного от имени администратора. Это гарантирует, что все необходимые файлы будут созданы, а пути и разрешения в IIS будут настроены корректно без ошибок доступа.

3. Проблемы с обновлением платформы 1С и путями к wsisapi.dll

После обновления платформы 1С мы можем столкнуться с ситуацией, когда в конфигурации веб-сервиса в IIS по-прежнему прописан путь к файлу wsisapi.dll из предыдущей, уже удаленной или неактивной версии платформы. Это, естественно, приводит к неработоспособности веб-сервисов. Для устранения этой проблемы мы можем предпринять следующие шаги:

1. Ручное исправление пути:
• Откроем Диспетчер служб IIS.
• Развернем узел «Сайты», затем выберем сайт, где опубликован наш веб-сервис (например, Default Web Site).
• В средней панели выберем нашу публикацию (приложение) и откроем «Сопоставления обработчиков».
• Найдем записи, относящиеся к обработке файлов 1С (например, с расширениями .1sc, .xml и т.д.), и проверим путь к модулю wsisapi.dll. Убедимся, что он указывает на актуальную версию платформы 1С (например, C:\Program Files (x86)\1cv8\8.3.16.1814\bin\wsisapi.dll).
• При необходимости изменим путь и сохраним изменения.
2. Повторная публикация веб-сервиса:

Самый надежный способ исправить устаревшие пути — заново опубликовать веб-сервис из конфигуратора 1С. Мы должны обязательно запустить конфигуратор 1С от имени администратора, чтобы обеспечить корректное обновление всех необходимых настроек в IIS.

4. Настройки IIS для обработки больших объемов данных (HTTP 413 "Request Entity Too Large")

Мы столкнулись с интересной ситуацией, когда простой метод веб-сервиса, возвращающий одну строку, работает, но методы, предназначенные для возврата больших объемов данных, завершаются с ошибкой. Это явный признак того, что мы могли превысить ограничения на размер запроса или ответа, установленные в IIS. IIS имеет несколько параметров, которые контролируют размер передаваемых данных:

1. maxAllowedContentLength:

Этот параметр в конфигурации IIS (обычно в файлах web.config или ApplicationHost.config) ограничивает максимальный размер содержимого, которое IIS разрешает отправлять в запросе. Мы можем увеличить его значение, чтобы разрешить передачу больших объемов данных.

Скопировать код

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="104857600" /> <!-- Пример: 100 МБ -->
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

2. uploadReadAheadSize:

Этот параметр управляет размером буфера, который IIS использует для предварительного считывания данных запроса. Если мы отправляем большие файлы или данные, увеличение этого параметра может помочь.

3. maxRequestLength:

Этот параметр используется в web.config для ASP.NET приложений и ограничивает размер входящего запроса. Хотя веб-сервисы 1С не являются напрямую ASP.NET приложениями, в некоторых сценариях этот параметр также может влиять на обработку больших запросов.

Скопировать код

<configuration>
  <system.web>
    <httpRuntime maxRequestLength="102400" /> <!-- Пример: 100 МБ в КБ -->
  </system.web>
</configuration>

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

5. Влияние кодировки и кириллицы на работу веб-сервиса

Особого внимания заслуживает случай из обсуждаемой темы, когда создание нового тестового метода с функцией, название которой было на кириллице, решило проблему, а затем перенос старого кода с заменой операторов с латиницы на кириллицу также привел к успешной работе. Это очень необычный, но показательный случай, указывающий на возможные проблемы с кодировкой или интерпретацией символов внутри платформы 1С или IIS.

Мы можем рассмотреть следующие моменты:

1. Единообразие кодировки: Убедимся, что все компоненты (операционная система, IIS, 1С) работают с одной и той же кодировкой, предпочтительно UTF-8. Если веб-страницы, логи или сообщения об ошибках отображаются "иероглифами", это свидетельствует о некорректной кодировке.
2. Явное указание кодировки: В некоторых случаях может потребоваться явное указание кодировки UTF-8 для страниц ошибок или в конфигурации IIS. Например, в web.config мы можем добавить:
   Скопировать код

   
   <system.web>
       <globalization culture="ru-RU" uiCulture="ru-RU" responseEncoding="utf-8" requestEncoding="utf-8" fileEncoding="utf-8" />
   </system.web>
   

3. Влияние имен и переменных: Хотя это кажется маловероятным в стандартных условиях, прецедент с кириллическими операторами из темы показывает, что иногда имена переменных, функций или других элементов кода могут влиять на поведение. Если мы сталкиваемся с подобной проблемой, можем попробовать стандартизировать названия, используя только латиницу или, наоборот, принудительно перевести критичные элементы на кириллицу для теста.

6. Дополнительные настройки и рекомендации для диагностики сбоев w3wp.exe

Помимо перечисленных выше шагов, мы можем рассмотреть ряд других настроек и методов диагностики, которые помогут нам глубже разобраться в причинах сбоев w3wp.exe с модулем ws.dll:

1. Установка компонентов IIS:

При установке IIS для работы с 1С критически важно убедиться, что установлены все необходимые компоненты. Мы проверим, установлены ли следующие:

• «Внедряемое веб-ядро службы IIS».
• «Компоненты разработки приложений», включая «Расширение ISAPI» и «Фильтры ISAPI».
• «Консоль управления IIS».
• Другие необходимые компоненты для веб-сервера.

Отсутствие этих компонентов может привести к тому, что IIS не сможет корректно обрабатывать запросы к 1С.

2. Анализ журналов событий Windows:

Подробную информацию о сбоях w3wp.exe мы всегда можем найти в журналах событий Windows (Просмотр событий -> Журналы Windows -> Система или Приложения). Тщательный анализ этих журналов может дать нам более точную подсказку о сбоящем компоненте, модуле или конкретной причине ошибки. Мы будем искать события с кодом 1000 или 1001, связанные с w3wp.exe.

3. Настройка типов MIME:

Мы убедимся, что типы MIME настроены корректно для обработки файлов 1С. В Диспетчере служб IIS для нашего сайта или приложения, мы проверим раздел «Типы MIME». Там должны быть прописаны соответствующие типы для файлов, используемых 1С (например, .1sc, .xml, .wsdl и другие, если требуется).

4. Версия IIS:

В исходной теме используется IIS 7.5. Хотя эта версия поддерживается для Windows 7 или Windows Server 2008 R2, обновление до более новой версии, такой как IIS 10.0, может значительно улучшить совместимость, производительность и стабильность работы с современными платформами 1С. Мы рассмотрим возможность обновления IIS, если другие методы не принесли результата.

5. Проверка web.config:

Мы тщательно проверим файл web.config в каталоге публикации на предмет синтаксических ошибок, опечаток или некорректных параметров. Даже небольшая ошибка в этом файле может привести к неработоспособности приложения.

6. Удостоверение пула приложений (Application Pool Identity):

Иногда временная смена удостоверения пула приложений на более привилегированную учетную запись (например, Local System), а затем обратно на Network Service или ApplicationPoolIdentity, может решить проблему, если она была связана с однократным выполнением какой-либо операции, требующей повышенных прав. Однако в долгосрочной перспективе рекомендуется использовать наименее привилегированную учетную запись, имеющую необходимые права.

В заключение, проблема публикации веб-сервисов 1С на IIS, проявляющаяся в сбоях w3wp.exe и отсутствии ответов на SOAP-запросы, требует комплексного подхода к диагностике. Мы начинаем с базовых проверок разрядности и прав доступа, а затем углубляемся в специфические настройки IIS, обработку больших объемов данных и даже необычные аспекты, такие как кодировка и названия элементов кода, как это было в описанном случае с кириллическими операторами. Последовательное применение этих шагов поможет нам выявить и устранить причину неисправности.