Как почистить кэш пользователя 1С на сервере

Кэш 1С — это служебные файлы, которые платформа создаёт для ускорения запуска и работы: скомпилированные модули, настройки интерфейса, временные метаданные. Со временем кэш устаревает или повреждается, и пользователь начинает видеть ошибки: «Ошибка формата потока», «Объект не найден», странное поведение форм после обновления конфигурации. В большинстве таких случаев первый и самый безопасный шаг — очистка кэша.

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

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

Где 1С хранит кэш: клиентские и серверные папки

Клиентский кэш каждого пользователя находится в его профиле Windows. Основные каталоги: C:\Users\ИмяПользователя\AppData\Roaming\1C\1cv8 и C:\Users\ИмяПользователя\AppData\Local\1C\1cv8. Внутри лежат папки с длинными именами — это GUID информационных баз. Каждой базе, к которой подключался пользователь, соответствует своя папка.

Папка Roaming содержит в основном настройки и журналы, а Local — основной объём кэша метаданных. Если нужно очистить кэш одной конкретной базы, удаляйте только её GUID-папку. Если определить GUID сложно, допустимо удалить все GUID-папки — при следующем запуске платформа создаст кэш заново, но первый вход в базу займёт больше времени.

Серверный кэш расположен в каталоге srvinfo агента сервера 1С. Типичный путь на Windows: C:\Program Files\1cv8\<версия>\srvinfo или путь, заданный при установке службы агента. Внутри находятся подкаталоги вида reg_1541 (номер зависит от порта кластера), а в них — папки с GUID баз и файлы серверного кэша, включая сеансовые данные.

Когда очистка кэша действительно нужна

Очистка кэша оправдана при конкретных симптомах, а не «для профилактики». Типичные признаки: ошибка «Ошибка формата потока» при открытии базы или отдельных форм, сообщения «Объект не найден» сразу после обновления конфигурации, у одного пользователя форма выглядит иначе, чем у остальных, база не запускается у конкретного сотрудника, хотя у коллег работает нормально.

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

Очистка клиентского кэша пользователя

Через список баз в окне запуска

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

Вручную через файловую систему

Классический способ: завершить все сеансы 1С у пользователя, открыть %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8, найти папку с GUID нужной базы и удалить её. Если GUID неизвестен — проще удалить все GUID-папки, оставив файлы настроек (1cv8cmn.pfl и подобные), чтобы не сбросить персональные настройки интерфейса.

1. 1
   Попросите пользователя закрыть все окна 1С и убедитесь, что процесс 1cv8.exe завершён в диспетчере задач
2. 2
   Откройте %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8
3. 3
   Удалите папки с GUID нужной базы (или все GUID-папки)
4. 4
   Запустите базу заново и дождитесь полной загрузки
5. 5
   Проверьте, исчезла ли ошибка, повторив действие, которое её вызывало

Удалённо через командную строку

Если у администратора есть доступ к компьютеру пользователя по сети, кэш можно удалить скриптом. Пример команды для PowerShell, выполняемой в сессии пользователя:

Get-ChildItem "$env:APPDATA\1C\1cv8", "$env:LOCALAPPDATA\1C\1cv8" -Directory | Where-Object { $_.Name -match '^[0-9a-fA-F-]{36}$' } | Remove-Item -Recurse -Force

Команда удаляет только папки, чьи имена соответствуют формату GUID, и не трогает файлы настроек. Запускать её нужно при завершённых процессах 1С, иначе часть файлов будет заблокирована и удаление пройдёт неполностью.

Очистка серверного кэша базы

Серверный кэш очищается реже и требует большей осторожности, потому что затрагивает всех пользователей базы. Порядок такой: в консоли кластера серверов завершите активные сеансы базы (или дождитесь, пока пользователи выйдут), остановите службу агента сервера 1С, удалите содержимое папки srvinfo\reg_1541 (кроме файлов, отвечающих за регистрацию самих баз, если вы не уверены в структуре — удаляйте только GUID-папки баз внутри), затем запустите службу.

Альтернатива без остановки службы — удалить информационную базу из кластера и зарегистрировать её заново с теми же параметрами. При этом серверный кэш базы пересоздаётся. Способ рабочий, но требует точного знания параметров подключения: СУБД, сервер баз данных, имя базы. Ошибка в параметрах приведёт к тому, что база не откроется.

Частые ошибки при очистке кэша

Самая распространённая ошибка — удаление кэша при запущенной 1С. Файлы блокируются процессом, удаляются частично, и после перезапуска проблема сохраняется или появляется новая. Вторая типичная ошибка — чистка только Roaming вместо Local: основной объём кэша лежит именно в Local, поэтому симптомы не уходят.

Третья ошибка — удаление всего содержимого srvinfo на сервере «для надёжности». Вместе с кэшем можно потерять регистрацию баз кластера, и восстановление потребует ручной перерегистрации каждой базы. Четвёртая — ожидание мгновенного эффекта: первый запуск после очистки всегда медленнее, и прерывать его нельзя.

Как проверить результат

После очистки запустите базу и повторите действие, которое вызывало ошибку. Если ошибка исчезла — причина была в кэше. Дополнительно убедитесь, что GUID-папки пересоздались: их появление означает, что платформа успешно построила новый кэш.

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

Профилактика и автоматизация

Регулярная «профилактическая» чистка кэша не нужна и даже вредна: она замедляет работу пользователей, заставляя платформа каждый раз пересоздавать кэш. Разумная автоматизация — скрипт очистки клиентского кэша по запросу при обращении пользователя с типичной ошибкой, а также регламентная проверка свободного места на диске сервера, так как переполнение диска с srvinfo — частая причина повреждения серверного кэша.

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

Частые вопросы