Помилки конфігурації програм. Помилки конфігурації програм Не можу прочитати файл з конфігураційними параметрами

Буває таке, що при необхідності настройки 1С в діалоговому вікні запуску вилітає помилка - «Не можу записати конфігураційного файлу». Давайте розберемося, чому виводиться таке повідомлення.

На замітку: Якщо Вас мучать такого роду проблеми і не хочете морочитися - шукати файли, що якось модифікувати в операційній системі, сміливо пишіть професіоналам - Smart1C.ru. Ми допоможемо вирішити проблеми і налаштувати облікову систему 1С під клас вирішуваних завдань.

Отже, приклади з життя:

До речі, якщо Ви цікавитеся темою вибору віртуального виділеного сервера, то раджу звернутися в компанію RackStore. На серверах включена можливість використовувати власне ПО, тобто 1С: Підприємство 8 можна використовувати і на віртуальному сервері.

Рішення проблем зі збереженням налаштувань 1С 8.2-8.3

Як бачимо, проблем зі збереженням налаштувань програми 1С може бути незліченна кількість. Всі ці ситуації можна вирішити в корені. А виправити це виявляється дуже легко. Важливо тільки вміти дивитися приховані файли і папки на комп'ютері. Для усунення цієї помилки робимо наступні дії.

Некоректна настройка програмного забезпечення (Прав доступу, відкриті порти, Интерфес) в результаті чого комп'ютерна система або дані можуть бути скомпрометовані. Найважливішим етапом написання будь-якого софта є його конфігурація під певні платформи для коректної роботи з ними.

Окремі особистості або групи зловмисників використовують подібні нестиковки у власних цілях.

Незалежно від характеру, будь-який збій призводить до ослаблення вбудованих захисних механізмів і робить машину вразливою перед хакерськими атаками.

Класифікація помилок конфігурації програм

Найбільш частою причиною помилок конфігурації програм є людський фактор. Адміністратор системи може не знати або забути закрити доступ до комп'ютерної системи, в результаті чого будь-який бажаючий від його імені зможе виконати будь-завгодно дії.

Основні помилки, які можуть використовуватися злочинцями для подальшого злому:

Несправність логічного типу виникають в процесі редагування конфігураційних параметрів, некоректного введення змінних для розрахунків або розбіжності окремих результатів, що швидше за все призведе до появи збоїв в роботі або повного зависання програми.
Системні помилки полягають в переповненні пам'яті, невірної переадресації, втрати даних або посиланнях на неіснуючі об'єкти.
Порушення цілісності структури.
Залишені активними налагоджувальні перемикачі для внесення розробниками змін в готовий продукт і виправлення виявлених багів; частина користувачів при інсталяції і перевстановлення ОС або ПЗ задають автоматичне включення додаткових функцій.
У Windows 10 досить часто присутні недоліки в текстових файлах, що містять дані про основні параметри конфігурації.
Повна відсутність або застарілі сигнатури антивірусного софту.

У всіх перерахованих вище випадках зловмисники будуть активно використовувати виникли неполадки для впровадження шкідливого коду або прихованого запуску різних додатків.

об'єкт впливу

Помилки конфігурації можуть виникнути в будь-якому додатку, однак найбільш уразливими для зломщиків є ті, які розташовані в системних файлах Windows, встановленому на серверах софт, в iTunes, програмних продуктах 1С і інших, що використовують багаторівневі інженерні розрахунки і гіперпосилання.

Основні причини виникнення помилок:

Застарілі версії компонентів ОС; можна встановити актуальні модифікації через центр оновлення Windows або завантажити їх вручну з офіційного сайту.
Несумісність окремих компонентів з елементами пакету Visual C ++, який входить в базову комплектацію багатьох ігор та інших програм. Вирішується видаленням застарілих версій і установкою актуальних для даної ОС, вкачає з офіційного сайту Microsoft.
Невірна паралельна конфігурація через некоректні ключів і записів в реєстрі виникає в разі неспівпадання версій заданих за замовчуванням системою бібліотек з останніми оновленнями. Для виправлення необхідно привести відповідні записи реєстру до значень за замовчуванням, перед початком редагування рекомендується створити точку відновлення.
Несумісність розрядності встановлюваного софту і ОС.

Причини виникнення помилок конфігурації

Основні джерела виникнення помилок конфігурації:

допущені творцями неточності в програмному коді, дизайні або реалізації, допущені в процесі розробки і написання програми;
невірна інсталяція продукту або недотримання рекомендацій розробників (наприклад, закрити запущені програми в процесі установки або відключити Інтернет);
зовнішні фактори: перебої з живленням або підключеного до нього обладнання, невірна робота драйверів чи інших компонентів ОС;
переповненість жорсткого диска або пам'яті, в результаті чого проведені зміни не зберігаються повністю;
недбалість, недосвідченість користувачів або навмисне заподіяння шкоди спільниками зловмисників;
деякі баги виникають в результаті комбінації скоєних раніше дій, які окремо не призводить до появи неполадок подібного роду;
випадкове або навмисне зовнішнє втручання з метою викликати збій і впровадити сторонній код, запустити вірус або троян, або встановити інше шкідливе ПЗ.

Аналіз ризику появи помилок конфігурації

Від появи подібних багів ніхто не застрахований. Вони можуть виникнути через невірні дії користувачів і після збоїв в роботі апаратної частини. Гірше, що виникають неполадки можуть використовуватися зловмисниками для зараження комп'ютера.

Якщо при установці або запуску з'явилося повідомлення про виявлену помилку конфігурації, необхідно виконати наступні дії:

перевірити сумісність інсталюється софта з операційною системою і її компонентами; якщо це є причиною конфлікту, можна спробувати встановити іншу версію або замінити програму аналогом;
спробувати запустити додаток з правами адміністратора;
перезавантажити комп'ютер; можливо, несправність носила разовий характер і після перезапуску системи не повториться;
перевірити версії компонентів Microsoft Visual C ++, при необхідності скачати їх з офіційного сайту компанії і перевстановити;
перевірити реєстр на відповідність пов'язаних з проблемним додатком параметрів значення за замовчуванням;
якщо перераховані вище кроки не дали необхідного результату, можна перевстановити додаток.

Для початку привожу список використовуваних мною скорочень:

РИБ - розподілена інформаційна база
ЦБ - центральна база, кореневий вузол РИБ
УБ - дистанційна база, БД віддаленого вузла РИБ

З власного досвіду можу сказати, що стикався з двома причинами виникнення помилки:

під час прийому файлу повідомлення в УБ "впала" база, в зв'язку з чим, мабуть, і сталася разсінхронізація між конф. ЦБ і УБ;
під MSSQL клієнт завантажив копію робочої бази і не вимкнув в копії регл. завдання автообміну, в результаті частина повідомлень в віддалені вузли формувалася з робочою БД, а частина з копії, що і призвело рассинхронизации конфігурацій

Є також думка, що до цієї помилку призводить використання механізму динамічного оновлення бази. Тут є сумніви, тому що з одного боку динамічне оновлення ніколи не зачіпає структури БД, а механізми РИБ все-таки працюють саме зі структурою БД, а не з прикладної її частиною, проте в РИБ використовується механізм формування цифрового підпису версії конфігурації (в надалі буду називати її для скорочення хешем), і при зміні прикладної частини хеш природно зобов'язаний перерахувати. Не буду ні заперечувати цього, ні стверджувати, тому що якщо і стикався з цією ситуацією, то явних доказів цього не знайшов.

Для виправлення використовую 2 методики, в залежності від ситуації.

ПЕРША МЕТОДИКА

Перша (найпоширеніша) неодноразово згадується і в партнерській конференції, і на інших інтернет-ресурсах пов'язаних з 1С. Застосовується в більшості випадків, коли незважаючи на повідомлення про розбіжності конфігурацій, при порівнянні вручну видається, що вони ідентичні.

Послідовність дій:

вивантажуємо з ЦБ cf-файл;
одв'язуємо УБ від РИБ (метод УстановітьГлавнийУзел, готову обробку можна знайти в додатку або в інших публікаціях);
замінюємо конф. УБ на розвантажений у першому кроці cf-файл, для цього користуємося меню "Завантажити конфігурацію з файлу" (а не порівнянням-об'єднанням !!!);
відновлюючи ознака РИБ для УБ.

У більшості випадків цих дій більш ніж достатньо, що відновити обмін, але не завжди ...

ДРУГА МЕТОДИКА

Застосовується в разі, якщо перша методика не спрацювала, а вивантажити заново вузол не представляється можливим.

Передісторія: у клієнта налаштовували каскадну РИБ і помилка виникла в першому рівні каскаду (другий рівень весь цей час працював бездоганно). Розробка конфігурації велася спільно з IT-службою клієнта і з моменту виникнення помилки конфігурація ЦБ встигла кілька разів помінятися. Варіант з відкотом змін не розглядався навіть у принципі, тому що втрата частини даних і зупинка роботи кількох підрозділів були абсолютно неприйнятні. Перший варіант виправлення помилки будь-яких відчутних результатів не дав. У зв'язку зі ніж довелося шукати інші шляхи вирішення.

Прийшла думка спробувати підмінити хеші файлів конфігурацій безпосередньо в XML-файлах обміну. Опис структури файла обміну з книги "Професійна розробка в системі 1С: Підприємство 8" дало слабке уявлення про формування цифрових підписів конфігурацій і змін в них, але визначило напрямок пошуку: значення Digest1 і Digest2. Все інше з'ясовував чисто емпіричним шляхом (чи то пак методом проб і помилок), але закономірність встановити таки вийшло.

Тестові експерименти пройшли вдало. На робочих базах теж все пройшло благополучно.

Отже, послідовність дій:

виконуємо дії 1 - 4 першої методики;
вивантажуємо з УБ файл обміну, але не завантажуємо його в ЦБ;
вивантажуємо з ЦБ файл обміну, але не завантажуємо його в УБ;
в файлі обміну з ЦБ замінюємо блок, що містить інформацію про зміни конфігурації і хеші (Digest1 і Digest2), на блок хеш з файлу УБ (приклад див. нижче)
виробляємо завантаження файлу з 4-го пункту в УБ;
обов'язково Перезаписуємо файл обміну з УБ (2-й пункт)! цей файл не повинен бути завантажений при обміні в ЦБ!
для перевірки робимо кілька послідовних обмінів.

Якщо при обміні використовується стиснення даних, то або відключаємо стиснення, або спочатку розпаковуємо файл, змінюємо, потім запаковуємо назад і відправляємо.

Блок файлу обміну з ЦБ

106.0
... тут йдуть блоки опису змін конфігурації ...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

потрібно замінити на блок файлу обміну з УБ (зверніть увагу Digest1 у файлу з УБ завжди дорівнює "00000000000000000000000000000000" !!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

Перераховані дії необхідно виконувати з граничною обережністю, некоректна послідовність чревата повною непрацездатністю РИБ. Тому перед цими діям створення резервних копій ОБОВ'ЯЗКОВО!

В іншому можу тільки побажати удачі!