Помогите что за ерунда. Замучался уже. Server 2008 клиент подключаются в файловом режиме по сети к базе и при закрытии месяца вот такая ерунда. Аварийное завершение.  И это происходит после обновления платформы.
Полная ошибка
Имя сбойного приложения: 1cv8c.exe, версия: 8.3.17.1851, метка времени: 0x5fb429b6
Имя сбойного модуля: ucrtbase.DLL, версия: 10.0.17134.12, метка времени: 0xbb0923b6
Код исключения: 0xc0000409
Смещение ошибки: 0x000a273b
Идентификатор сбойного процесса: 0x2328
Время запуска сбойного приложения: 0x01d81cba6b454833
Путь сбойного приложения: C:\Program Files (x86)\1cv8\8.3.17.1851\bin\1cv8c.exe
Путь сбойного модуля: C:\Program Files (x86)\1cv8\8.3.17.1851\bin\ucrtbase.DLL
Идентификатор отчета: 41dc51b0-88b1-11ec-85ee-94de80e57bea
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:
С++ обновляю до самого нового на сервере.

https://forum.infostart.ru/forum86/topic200884/

(0) Платформа точно не ломаная?

Нет. Стоит ключ сетевой и на 10 пользователей

64 битную платформу пробовали?

Там server 2008 86

(5) жость.
А есть возможность прописать путь через айпи?

(5) тогда эта папка откуда?  Program Files (x86)   ?? Значит, кто-то врет?

На сервере стоит 86 на клиенте 64. То есть можно на клинте 64 поставить да.

Что значит ?

А есть возможность прописать путь через айпи?

На сервере 86 система на клиенте 64 разрядная. Везде стоит 1с 32 разрядная. То есть на клиенте можно установить 64 1с?

(11) не работал с файловыми. Но, вроде смысла в 64 битах не много

Так вот и не понимаю из за чего падает

(13) пробовали (6)?

1Сергей Что именно пробовал

(15) путь к базе вместо \\server2008\BaseName прописать \\192.168.1.1\BaseName

ок

Причем тут пути? Ошибка это чисто внутренняя, порча стека. Это либо баг конкретного релиза, либо несовместимость с какой-то системной библиотекой. А может антивирус порет.

Предлагаю поискать на багтрекере 1С по имени библиотеки. Если нет, то обратиться в поддержку и решать с ней.

Не надо работать с файловой базой по сети

Chai Nic Ну тут такая ситуация и всего два человека сидит на данный момент

Путь 192.168.*.* не помогает

Опять вылетает

(0)
на вот, почитай на ночь. Кому-то 64х помогает, кто-то в свойствах сетевой карты флаги выставляет. Кто-то подорожник прикладывает.
Но чаще, забивают болт
https://forum.infostart.ru/forum9/topic223586/

вот это сделай оттуда:
>>>>> в свойствах сетевой карты параметр "Разгрузка при большой отправке (IPv4)" установлен в значение "Выключен"

(24) Это из той же серии, что

>в хост (в файл hosts) добавить строку: 127.0.0.1 baidu.cn или ещё что-то ограничить

Попинать колеса, протереть фары...

На сервере или на клиенте?
в свойствах сетевой карты параметр "Разгрузка при большой отправке (IPv4)" установлен в значение "Выключен"

Это не может влиять при установке платформы. решил 18 поставить
https://cloud.mail.ru/public/ho4j/9guUvDSdg

(25) ну, кому-то помагает..
ХЗ, не было файловой по-сети, не с чем сравнивать

может имеет смысол перейти на вэб? Файловую вроде можно опубликовать в апаче

в апаче пробовал ошибки часто тоже появляются. И вся это канитель после новой платформы.

(29) +1. В файловой базе надо работать через веб-сервер. Напрямую с файлом работать в файловой базе можно только если база локальная однопользовательская.

Многие каждый раз пишут левая? Если ломанная проверку если не ошибаюсь не проходит.
https://cloud.mail.ru/public/ZPbn/edyWN9unp

https://answers.microsoft.com/ru-ru/windows/forum/all/имя/97d322bc-ab6f-41eb-8667-e024559d8b4b
Как бы это runtime library, и в ней,судя по всему,просто ошибка - тут даже 1с не виновата.

Это я к чему,если поискать по имени этой dll,то ошибка-то таже самая,но пользователи там про 1с не знают.предлагается искать обновление Си 2017.

ДедМорроз так самые последние ставлю и на серваке и на клиентах

Если ты внимательно почитаешь ссылку,то заметишь,что после обновления windows что-то сломалось - значит - нужно попробовать не самую последнюю библиотеку.

Ну или ставить версию платформы,где другая версия библиотеки,в принципе.

Вот https://cloud.mail.ru/public/SZXP/kRRfRL6Qv

От 2005 до 2022. Причем на всякий старые удалил и новые поставил

Может вообще все удалить и только 2017 поставить которая с платформой идет?

На самом деле,все действия - это танцы с бубнами.
Сейчас я попытаюсь объяснить причину ошибки.
У нас есть dll, в данном случае ucrlbase,как и у любой dll все данные в ней разбиты на секции,которые грузятся в память по определенным адресам,называемым базовыми адресами,но базовый адрес в адресном пространстве процесса может быть занят,тогда делается загрузка по другому адресу и используется таблица переразмещения,которая правит ссылки.
Но,может оказаться,что одну из ссылок в dll забыли добавить в таблицу переразмешения,п базовый адрес этого сегмента выбрали так,что он ни с чем не пересекается.
Когда dll отлаживают,она грузится по базовому адресу (для этого сегмента)и все работает как часы.
Потом эту dll используют во многих программах,в том числе и в 1с,и все также работает как часы.
Но,в какой-то из программ,использующих целевую dll используется еще и dll "простая 1",которая грузится совершенно по другому адресу и никак не мешает нашей.
Потом,встречается программа или служба,использующая также dll "простая",но кроме нее еще и dll "совсем простая", которая по какому-то стечению обстоятельств перекрыла базовый адрес dll "простая".
Тут еще нужно отметить интересное поведение windows,что dll грузится по базовому адресу,а если не может загрузиться,то по любому свободному,с использованием переразмещения.
Но,в целях экономии памяти,если dll зашружена по какому-то адресу в один процесс,то в другой она будет грузиться сначала не по базовому,а уже используемому адресу,так как в этом случае,память под код dll у обоих процесмов будет общей.
В итоге,по какой-то причине у процесса,запускающегося ранее нашего,используемая dll "простая" попадает в блок адресов нашей dll. Так как этот процесс о нашей dll не знает,а в dll простая ошибки перераспределения нет,то он работает без ошибок.
А вот теперь запускается наш процесс,который сначала грузит dll "простая" и занимает адрес нашей dll,так как в другом процессе она использует этот же адрес,а потом грузит нашу dll, вызывая переразмешение,которое приводит к битой ссылке внутри нашей dll,и процесс падает со странной ошибкой.
И,понять суть проблемы очень тяжело,а также непросто выявить ошибку первоначального распределения адресов,так как нагадивший процесс,в котором две произвольных dll столкнулись базовыми адресами,может быть уже давно завершен.
А потом думайте - может ли одна программа повлиять на другую - оказывается может,причем так,что никто сразу и не разберется.

(41) Ты гонишь.

> в целях экономии памяти,если dll зашружена по какому-то адресу в один процесс,то в другой она будет грузиться сначала не по базовому,а уже используемому адресу,так как в этом случае,память под код dll у обоих процесмов будет общей

В Windows вся память виртуальная, у каждого процесса свое адресное пространство. Адрес для размещения dll выбирается без оглядки на другие процессы или физ. адрес.

>dll грузится по базовому адресу,а если не может загрузиться,то по любому свободному,с использованием переразмещения

По базовому адресу ничего не грузится уже очень давно, из-за ASLR.

>Но,может оказаться,что одну из ссылок в dll забыли добавить в таблицу переразмешения,п базовый адрес этого сегмента выбрали так,что он ни с чем не пересекается.

Наверное, это может случиться с какой-нибудь "dll простая", которую студент транслировал и собирал вручную, но не с Microsoft C Runtime Library. :)

Кроме того, 1C использует не общесистемную версию этой библиотеки, а свою собственную, которая грузится только в процессы 1С.

Это конечно все хорошо но для меня заумно :)

(43) А это не для тебя. :) Для тебя (18)

(42) у dll есть параметр,определяющий использование страниц кода,они могут проецироваться в адресное пространство сразу нескольких процессов без проблем,главное,чтобы виртуальные адреса совпадали.
Иначе бы,например,user32 было бы столько,сколько процессов,а так для вмех процессов одна копия в ФИЗИЧЕСКОЙ памяти.

(0) Попробуйте добавить в исключения антивируса/Защитника Windows исполняемые файлы 1с и пути к платформе. У меня пару лет назад Розница на одной точке таким же образом постоянно валилась с ошибкой, такой вот ход конём помог.

(3) Ну и насчёт веб-сервера непонятно, у вас там точно такая же ошибка? То есть и толстый клиент в файловом режиме, и тонкий клиент через веб-сервер выдают в точности одно и то же? Это очень странно, если так, сложно поверить. Попробуйте в таком случае доступ через браузер, уж там-то точно такой ошибки быть не может.

(45) >для вмех процессов одна копия в ФИЗИЧЕСКОЙ памяти

Это для всех библиотек так, не только для user32. Но виртуальные адреса разные. В этом смысл "проецирования".