При переходе с 32-битной на 64-битную платформу 1С:Предприятие администраторы часто сталкиваются с тем, что ранее работавшие веб-сервисы перестают функционировать, выдавая внутреннюю ошибку сервера — HTTP 500. Это происходит из-за конфликта разрядности рабочих процессов веб-сервера IIS и используемых библиотек 1С. В данной статье мы подробно разберем, как правильно настроить среду для работы с x64 платформой, проанализируем основные причины сбоев и пошагово пройдем путь от возникновения ошибки до стабильно работающего сервиса.
Одной из наиболее частых причин возникновения ошибки 500 является неправильная конфигурация пула приложений в IIS. По умолчанию пулы могут быть настроены на работу в 32-битном режиме (WOW64). Если ваша публикация ссылается на 64-битную версию платформы 1С, но пул приложений пытается запустить ее в 32-битном окружении, произойдет критический сбой.
Рассмотрим процесс настройки пула приложений:
DefaultAppPool или созданный вручную пул для 1С).Проанализируем ситуацию: когда этот параметр установлен в True, рабочий процесс w3wp.exe запускается как 32-разрядный. Он физически не может загрузить 64-разрядную библиотеку wsap22.dll, находящуюся в C:\Program Files\1cv8\.... Установка значения False заставляет IIS запускать полноценный 64-битный процесс.
После настройки пула приложений нам необходимо убедиться, что сама публикация веб-сервиса указывает на правильный программный модуль. Разберем, как проверить файл web.config, который находится в папке с публикацией базы.
Найдем в файле web.config секцию handlers. В ней должен быть прописан путь к библиотеке расширения веб-сервера 1С. Посмотрим на пример корректной записи для 64-битной платформы:
<handlers>
<add name="1C Web-Service Extension"
path="*"
verb="*"
modules="IsapiModule"
scriptProcessor="C:\Program Files\1cv8\8.3.23.1865\bin\wsap22.dll"
resourceType="Unspecified"
requireAccess="Execute" />
</handlers>
Важно обратить внимание на параметр scriptProcessor. Если там указан путь C:\Program Files (x86)\..., то система будет пытаться вызвать 32-битный модуль, что приведет к ошибке при 64-битном пуле приложений. Убедимся, что путь ведет именно в Program Files.
Выясним причину, по которой даже при правильных путях IIS может блокировать запуск модуля. В системе безопасности IIS существует список разрешенных расширений. Если вы установили новую версию платформы x64, ее необходимо "легализовать" в настройках сервера.
wsap22.dll.Без этой настройки IIS будет блокировать попытки исполнения библиотеки, возвращая ошибку доступа или всё ту же неопределенную 500-ю ошибку.
Переход на x64 означает смену физического расположения файлов платформы. Проанализируем типичную ошибку: права на папку C:\Program Files (x86)\1cv8 были настроены, а на новую папку C:\Program Files\1cv8 — нет.
Для корректной работы веб-сервиса пользователь, от имени которого запущен пул приложений (обычно это IIS AppPool\ИмяВашегоПула или IUSR), должен иметь права на Чтение и выполнение для каталога bin установленной платформы.
Выполним следующие шаги:
C:\Program Files\1cv8.Если вышеперечисленные действия не помогли, нам нужно получить более детальную информацию о том, где именно происходит сбой. Рассмотрим инструмент Failed Request Tracing. Он позволяет создать подробный отчет в формате XML, в котором будет зафиксирован каждый этап прохождения HTTP-запроса через конвейер IIS.
Включив этот модуль, мы сможем увидеть, на каком именно этапе возникает MODULE_SET_STATUS с кодом 500. Чаще всего там будет указана конкретная причина: 0x800700c1 (не является допустимым приложением Win32), что прямо указывает на конфликт разрядности (битности) между пулом и библиотекой wsap22.dll.
Для стабильной работы расширений 1С убедимся, что в системе включены все необходимые компоненты IIS. Проверим это через Включение или отключение компонентов Windows:
Без этих компонентов IIS просто не поймет, как обрабатывать запросы, направленные к DLL-файлам.
После внесения изменений в настройки разрядности пула приложений или изменения системных переменных, простого рестарта веб-сайта может быть недостаточно. Проанализируем ситуацию: некоторые библиотеки могут оставаться заблокированными в памяти процессами WOW64.
Рекомендуется выполнить полный сброс состояния веб-сервера. Для этого запустим командную строку от имени администратора и выполним команду:
iisreset
Это гарантированно завершит все рабочие процессы и принудит IIS перечитать конфигурацию пулов приложений, применив настройки 64-битного режима.
Подведем итог: Основная сложность при переходе на x64 в IIS заключается в строгом соблюдении единообразия разрядности. Все звенья цепи — Пул приложений, Файл web.config, Ограничения ISAPI и Физические права доступа — должны быть настроены на работу с 64-битной платформой 1С. Тщательное следование приведенным шагам позволит вам быстро локализовать и устранить ошибку 500.