Где 1С:Предприятие хранит кэш на клиенте и сервере и когда его пора сбрасывать

Кэш 1С — это копия конфигурации и служебных данных, которую платформа держит на диске, чтобы не тянуть их из базы при каждом запуске. На компьютере пользователя он лежит в %LOCALAPPDATA%\1C\1cv8\ и %APPDATA%\1C\1cv8\, на сервере — в каталоге srvinfo\reg_1541. Очистить клиентский кэш проще всего параметром запуска /ClearCache или удалением папки базы при закрытой 1С.

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

Как устроено кэширование на стороне клиента

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

Отсюда и выигрыш: открытие базы по медленной сети или в сервере 1С занимает секунды, а не минуты. Отсюда же и проблемы: если сверка по какой-то причине сбилась, клиент продолжает работать со старой или битой копией.

Что лежит на компьютере пользователя:

Каждая база получает свою папку с именем вида 5d2f1c3a-8e4b-4f0a-9c7d-2b6e1a0f3c48. Это идентификатор записи в списке баз, его видно в файле ibases.v8i в строке ID=. По нему легко найти папку нужной базы, не удаляя кэш остальных.

Если на компьютере работает несколько пользователей Windows, у каждого свой профиль и свой кэш. На терминальном сервере это особенно заметно: чистить нужно в профиле того пользователя, у которого проблема, а не у администратора.

Временные файлы на сервере 1С

В клиент-серверном варианте кэш есть и у кластера. Рабочие процессы держат на диске сеансовые данные и служебные копии конфигурации. Всё это живёт в каталоге службы, по умолчанию C:\Program Files\1cv8\srvinfo\. Фактический путь задаёт ключ -d в командной строке службы «Агент сервера 1С:Предприятия 8.3».

Структура каталога:

• 📁 srvinfo\reg_1541\ — данные кластера, работающего на порту 1541;
• 📄 1CV8Clst.lst — реестр кластера: список баз, рабочих серверов, администраторов;
• 📁 папки с GUID баз — журнал регистрации, полнотекстовый индекс и другие данные конкретной базы;
• 📁 snccntx<GUID> — кэш сеансовых данных, который и чистят при сбоях.

Файл 1CV8Clst.lst не удаляйте ни при каких условиях. Без него кластер «забудет» все зарегистрированные базы, и их придётся подключать заново. Папки баз тоже не трогайте: в них журнал регистрации, который потом не восстановить.

Признаки, что проблема в серверном кэше, а не в клиентском:

• 🖥️ ошибка воспроизводится у всех пользователей, в том числе на чистом компьютере;
• 🔁 после очистки клиентского кэша ничего не меняется;
• 📈 каталог snccntx вырос до нескольких гигабайт;
• ⚠️ после аварийной перезагрузки сервера сеансы не создаются или падают с ошибками сеансовых данных.

Очистка кэша сервера: порядок действий

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

1. Попросите всех выйти из 1С или дождитесь окончания рабочего дня.
2. Откройте services.msc и остановите службу «Агент сервера 1С:Предприятия 8.3».
3. Убедитесь в диспетчере задач, что не осталось процессов ragent.exe, rmngr.exe, rphost.exe.
4. Откройте srvinfo\reg_1541\ и скопируйте на всякий случай 1CV8Clst.lst в отдельную папку.
5. Удалите папки, имя которых начинается с snccntx.
6. Запустите службу и проверьте вход в базу.

Те же шаги в командной строке с правами администратора:

rem Имя службы смотрите в свойствах службы, поле «Имя службы»
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"

cd /d "C:\Program Files\1cv8\srvinfo\reg_1541"
copy 1CV8Clst.lst D:\backup\1CV8Clst.lst
for /d %%D in (snccntx*) do rd /s /q "%%D"

net start "1C:Enterprise 8.3 Server Agent (x86-64)"

На Linux логика та же: остановить службу сервера 1С через systemctl, удалить папки snccntx* в каталоге reg_1541 пользователя usr1cv8 и запустить службу обратно.

Сброс кэша параметром /ClearCache

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

Запустить 1С с этим параметром можно из командной строки или ярлыка:

rem Файловая база
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8c.exe" ENTERPRISE /F"D:\Bases\Buh" /ClearCache

rem Клиент-серверная база: сервер\имя базы
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8c.exe" ENTERPRISE /S"srv1c\buh" /ClearCache

Номер версии в пути подставьте свой: посмотрите, какая папка есть в C:\Program Files\1cv8\. 1cv8c.exe — тонкий клиент, 1cv8.exe — толстый, параметр работает с обоими.

Очистка из окна запуска 1С без командной строки

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

1. Откройте окно запуска 1С:Предприятия со списком баз.
2. Выделите нужную базу и нажмите Изменить….
3. Нажимайте Далее, пока не дойдёте до последней страницы мастера.
4. В поле Дополнительные параметры запуска впишите /ClearCache.
5. Нажмите Готово и запустите базу.
6. После успешного входа снова откройте Изменить… и уберите параметр.

Последний шаг не пропускайте. Если оставить /ClearCache навсегда, база при каждом входе будет скачивать конфигурацию заново и открываться медленно.

Ручное удаление папки кэша

Второй вариант — удалить папки руками. Он нужен, когда база падает ещё до появления окна входа или когда проблема у нескольких баз сразу.

1. Закройте все окна 1С. Проверьте в диспетчере задач, что нет процессов 1cv8.exe и 1cv8c.exe.
2. Нажмите Win+R, введите %LOCALAPPDATA%\1C\1cv8 и нажмите Enter.
3. Удалите папку нужной базы (её GUID — в ibases.v8i) или все папки с именами-идентификаторами.
4. Повторите то же для %APPDATA%\1C\1cv8, если проблема не ушла.

Для администратора, который обслуживает много рабочих мест, удобен скрипт PowerShell. Он удаляет только папки с именами-GUID и не трогает список баз и общие настройки:

# Закройте 1С перед запуском
if (Get-Process 1cv8, 1cv8c -ErrorAction SilentlyContinue) {
    Write-Host "1С запущена. Закройте все окна программы."
    exit 1
}
$guid = '^[0-9a-fA-F]{8}-([0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}$'
"$env:LOCALAPPDATA\1C\1cv8", "$env:APPDATA\1C\1cv8" | ForEach-Object {
    if (Test-Path $_) {
        Get-ChildItem $_ -Directory |
            Where-Object { $_.Name -match $guid } |
            Remove-Item -Recurse -Force
    }
}
Write-Host "Кэш 1С очищен."

Сравнение способов:

Кэш в файловом режиме работы

В файловом варианте отдельного сервера 1С нет. Роль сервера выполняет сам клиентский процесс, который открывает файл 1Cv8.1CD напрямую. Поэтому серверного кэша snccntx здесь не существует: всё, что описано про srvinfo, к файловой базе не относится.

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

Что ещё есть в каталоге файловой базы:

• 📄 1Cv8.1CD — сама база, удалять нельзя;
• 📁 1Cv8Log — журнал регистрации;
• 📁 1Cv8FTxt — полнотекстовый индекс, его можно перестроить, но это не кэш конфигурации;
• 📄 1Cv8tmp.1CD — временный файл, который 1С создаёт во время работы.

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

Признаки битого кэша и профилактика

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

Что снижает риск проблем с кэшем:

1. 🔒 Обновляйте конфигурацию, когда в базе никого нет. Пользователи, сидевшие в базе во время обновления, — главный источник рассинхронизации.
2. 🔄 После обновления платформы на сервере обновите и клиентов до того же номера сборки.
3. 💾 Следите за свободным местом на диске C: пользователей и сервера: кэш при нехватке места записывается не полностью.
4. 🛡️ Добавьте каталоги %LOCALAPPDATA%\1C\1cv8 и srvinfo в исключения антивируса по согласованию со службой безопасности. Сканирование на лету замедляет работу и может блокировать запись.
5. 🧹 Не настраивайте регулярную принудительную очистку кэша «для профилактики». Без причины она только замедляет первый вход и ничего не даёт.

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