Проблема случайных задержек или полного отсутствия печати в связке 1С 7.7 и Windows Server 2012 R2 (через RDP) является классической «головной болью» системных администраторов. Ситуация, когда документ уходит на печать, но физически распечатывается только через час или на следующий день, часто ошибочно списывается на «плохие драйверы». На самом деле причина кроется глубже — в конфликте архитектур 32-битного приложения, 64-битной серверной ОС и механизмов проброса портов. Рассмотрим подробно, как диагностировать и устранить эти неисправности.
Проанализируем, как 1С 7.7 взаимодействует с принтерами. Это старое 32-битное приложение, которое сохраняет настройки принтера (включая его имя) в реестре или в файлах параметров пользователя (mxl файлы, 1Cv7.CFG). При использовании стандартного механизма проброса принтеров (Windows Easy Print) имя принтера в каждой новой сессии меняется. Например, сегодня принтер называется «HP LaserJet (перенаправлено 15)», а завтра — «HP LaserJet (перенаправлено 22)».
Суть проблемы: 1С пытается отправить задание на принтер с конкретным номером сессии, который уже не существует. Это вызывает подвисание диалога печати или накопление заданий в очереди диспетчера печати (spooler), пока система не переинициализирует очередь или не принудительно очистит старые ссылки. Для решения этой проблемы рекомендуется отказаться от автоматического проброса через Easy Print и использовать сетевые принтеры с постоянными именами либо специализированные утилиты типа ScrewDrivers, которые создают статичные виртуальные порты для каждого пользователя.
Так как наша платформа 1С 7.7 является 32-битной, а Windows Server 2012 R2 — 64-битной, любое взаимодействие с подсистемой печати происходит через процесс-посредник splwow64.exe (Thunking Host). Этот процесс транслирует вызовы из 32-битной среды в 64-битную очередь печати.
Рассмотрим ситуацию: при большом количестве пользователей (60-70 человек, как в нашем случае) этот процесс может «засыпать» или блокироваться из-за одного некорректного запроса от старого драйвера. По умолчанию splwow64.exe завершается через некоторое время бездействия, и его повторный запуск при печати из 1С может занимать значительное время, создавая эффект зависания. Чтобы оптимизировать его работу, проанализируем настройки реестра:
Посмотрим на параметр Splwow64TimeOut, который находится в ветке:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print
Если увеличить время жизни этого процесса, мы уменьшим количество задержек при инициализации печати. Однако стоит помнить, что бесконечное время жизни может привести к утечкам памяти в сессиях.
Одной из наиболее частых причин «случайного» характера проблем является влияние драйверов разных принтеров друг на друга. В терминальной среде Windows Server 2012 R2 драйверы по умолчанию могут работать в общем адресном пространстве службы spoolsv.exe. Если драйвер локального принтера одного пользователя (например, дешевого домашнего МФУ) даст сбой, он может «уронить» или подвесить всю службу печати для остальных 70 пользователей.
Разберем шаги по настройке изоляции:
Это гарантирует, что каждый драйвер будет работать в отдельном процессе. Если драйвер «глючного» принтера зависнет, это не повлияет на общую очередь печати сервера.
При каждом входе пользователя через RDP создается виртуальный порт печати. В Windows Server 2012 R2 иногда возникает ошибка, при которой старые порты от завершенных сессий не удаляются корректно. Выясним, к чему это ведет: когда количество «мусорных» портов в реестре доходит до критического значения (сотни или тысячи), подсистема печати начинает тратить колоссальное время на перебор портов при каждой попытке напечатать документ. Это объясняет, почему печать может начаться «через час» — сервер просто долго «продирается» через список невалидных портов.
Проверим ветку реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Ports
Если вы видите там сотни записей типа TS001, TS002, необходимо настроить скрипт очистки этих портов при выходе пользователя или регулярно перезапускать службу печати Spooler с предварительной очисткой этих веток.
1С 7.7 при формировании печатных форм активно использует системную папку %TEMP%. В терминальной среде Windows Server 2012 R2 файлы в этой папке имеют свойство накапливаться. Проанализируем техническое ограничение: если в папке Temp скапливается более 65 535 файлов, создание нового временного файла операционной системой становится невозможным или крайне медленным. Это напрямую блокирует процесс формирования задания на печать.
Рекомендуем внедрить следующую практику:
C:\Windows\Temp.Как отмечалось в обсуждении на форуме, отказ от автоподключения (Printer Redirection) в пользу классических сетевых принтеров часто решает проблему радикально. Если филиал связан с головным офисом по VPN, попробуем прописать принтеры как сетевые устройства непосредственно на терминальном сервере, минуя проброс через RDP-канал. Это позволит избежать зависимости от .NET Framework клиента (который критичен для Easy Print) и устранит проблему динамических имен.
Подведем итог: для решения проблемы случайной печати в 1С 7.7 недостаточно просто «переустановить дрова». Необходимо подойти к вопросу комплексно: изолировать процессы драйверов, следить за чистотой реестра от устаревших TS-портов, контролировать количество файлов в Temp-директориях и, по возможности, перейти на статические способы подключения принтеров. Рассмотрим внедрение сторонних решений типа ScrewDrivers только в том случае, если стандартные средства оптимизации Windows Server не дают стабильного результата при вашей нагрузке в 70 пользователей.