Usually the error occurs when there was a failure during the configuration saving process. As a result, the Configuration was not saved correctly.
1. Try to check through testing and fixing or ChDBFl.exe
2. Look at the following solutions to the problem:

In some cases it helps complete cleaning CACHE, In Windows 7 OS there is C:\Users\Administrator\AppData\Roaming\1C\1Cv82 and C:\Users\Administrator\AppData\Local\1C\1Cv82 (Win7x64).

Or more details:
1. A clean configuration of the same version is required - working.
2. Clear the cache completely (indicated above).
3. Launch a clean database in configurator mode and open the configuration. At the same time, 1C creates its cache in C:\Users\Administrator\AppData\Local\1C\1Cv82 (a set of files and folders in the folder with the configuration ID.) We also need a cache in C:\Users\Administrator\AppData\Roaming\1C \1Cv82. You can simply rename the folder data after closing 1C.
4. Launch our non-working database in configurator mode and look at the cache. And as a result, we have two folders with configuration IDs (Alive and Dead).
5. Close everything and replace the cache of the dead conf with a live one completely. Those. delete the current one and replace it with the previously renamed folder.
6. We launch a non-working database in configurator mode AND HERE is the first success - the configuration tree is open, sections of the configuration management menu are active.
7. Go to support management and remove support completely. save, update. You can update it via a file with the working database configuration.
8. Delete the cache completely.
9. We launch a non-working database in configurator mode, try to open the configuration - everything opens, there are no errors.
10. Launch 1C. Everything is available. The data is in place.

There was the same message when I dynamically updated the configuration of the central database and made an exchange on the peripheral one and a similar message appeared on the peripheral one.
1. Because I couldn’t access the configurator on the peripheral at all, so I had to delete the folder C:\Documents and Settings\Admin\Application Data\1C\1Cv81.
2. Go to the configurator and select Configuration - Database configuration - Return to database configuration.
3. MainNode set undefined.
4. Configuration - Load configuration from file (central configuration).
5. The MainNode has installed the required one.

I had a similar situation, but on 8.1. During the dynamic update of the configuration, apparently there was a failure, after which an attempt to unload both the Main conf and the DB conf and when I further tried to load the file into the local database, the message “the integrity of the configuration structure was violated” was thrown out. But the database is functional. Neither testing and fixing nor ChDBFl.exe yielded anything.

I made a backup of the working database and loaded it into a clean database. Added exchange plan
http://kb.mista.ru/article.php?id=7
and created the Initial image. The configuration in the image database has been corrected.

If it doesn’t help, I can recommend the option that I wanted to resort to myself:
1. find the nearest configuration release, load it into a clean database (recoverable).
2. create a completely clean database (intermediate)
3. open the configurator of the damaged database.
4. copy and paste modules and objects in which changes have occurred since the last release (in my case it is much easier, since changes occurred only in modules and forms, the data structure remained the same and all changes are documented by posters) from the damaged database to the intermediate one.
5. Upload the intermediate configuration.
6. Merge it with the database being restored.
7. Upload the restored configuration to a file.
8. Load the configuration from the one being restored into the damaged database.

In theory, the result should be as close as possible to the working base, but the work is certainly not easy. But it’s still better than losing the entire base.

Another option to solve the problem associated with corrupted vendor configuration. When updating a configuration that is supported with the ability to edit and the integrity of the vendor configuration is compromised, the following message may appear:

My solution is to replace our database provider configuration.
The sequence of actions is as follows:
1. Delete the vendor configuration by removing it from support (Configuration->Support->Support Settings->Remove Support)
2. Create a configuration delivery file (Configuration->Configuration delivery->Create delivery files and configuration updates). Let's call the file work delivery file.cf
3. We combine our configuration with the newly created delivery file (Configuration->Compare, merge with the configuration from the file). You will be prompted to put the configuration back into support.
In the configuration comparison window that appears, click “Run”
4. Update the database configuration (Configuration->Update database configuration).
Ideally, by performing these steps, we restructured the supplier configuration.
Now we can try to update our configuration to the next version as usual.

Today I will tell you about what actions to take if, after updating the 1C 8.2 configuration, the error “The integrity of the configuration structure has been violated” appears.
So, to the point: you can try to solve the problem as follows (before starting any of the configuration actions, do not forget to do archival copy database, I wrote how to do this in a note):

• Create a new empty database in a new folder and load the previously unloaded one into the configuration information base, which needs to be updated.

If we use this option as a solution to the problem in principle, the inconvenience is that during multi-user work we will have to rewrite the paths to the database. Let's try to update this configuration and then run it.

If the problem is resolved, then most likely you need to clean the 1c cache folder ( C:\Documents and Settings\User\Local Settings\Application Data\1C\1Cv82). The folder will most likely be hidden by default, so if you don't know how to access hidden files And windows folders, I recommend reading the note. Files in the root folders 1Cv82 and 1Cv81 with the current/last modified date should not be touched. They store the start window settings. Everything will start in this case, but then you will have to wait the first time you start it.

After solving the problem (if, of course, the proposed method helps you), I recommend making an archive copy of the database again and checking the configuration for errors using the standard 1C “Testing and Correction” tool.

Information security testing and correction

You need to go to the configurator and in the “Administration” menu item select “Testing and correction”:

The tool operates in 2 modes

• Testing is a mode that only checks for configuration errors.

• Testing and correction is a mode in which both configuration errors are checked and corrected.

When the information base operates in file version and work option client-server, it is permissible to test and correct logical integrity, referential integrity and recalculate totals, For file version information base, it is possible to perform re-indexing and database compression.

For distributed infobases (DIBs), from which it is possible to receive data containing links to objects that are not in the infobase under test, uncheck Checking the referential integrity of the infobase will allow you to disable the creation of “non-existent” data and, as a result, will not lead to the transfer of this data to other nodes of the distributed information base.

It is impossible to enable IS referential integrity checking while disabling logical integrity checking. Also, disabling referential integrity checking does not mean that reference type checking is disabled.

The weakest point, for example in Accounting, is the Turnover Balance Sheet, so before and after processing, I recommend creating a balance sheet and comparing the final indicators before and after testing and correction. This, of course, is not the apogee of testing, but at least it’s something.

That's all I wanted to tell you today. Until next time.

The dynamic update failed. The program remained available to users in Enterprise mode, but the configurator stopped opening.

Initial data: 1C Enterprise 8.3, client-server database, MS SQL 2012, backup configured using MS SQL, backups are created once a day, at night.

The configuration is modified and active work is underway on it, so I had a second server base in which development was carried out, plus there were uploads to dt from both bases on the previous day. The article will use “MyBase” as the name of the working database, and “MyTestBase” as the name of the backup server database.

In my case, the ConfigSave database table was empty, as in the described materials, and the Config and Params tables contained rows with the value "DynamicallyUpdated" in the FileName field

Materials from the network that I used to solve the problem:

The customer decided to carry out restoration work at the end of the working day with the risk of losing data for the current day (in the event of failure of the recovery procedure and the need to roll back to a night backup).

To resolve the problem, the following steps were performed:

1. All 1c user sessions are disabled

2. Through the 1c servers management console, the start of sessions has been blocked and the launch of routine tasks has been cancelled.

3. A backup of the working database was made using MS SQL using SQL Server Management Studio. Queries from tables

records with "DynamicallyUpdated" values ​​in the FileName field were removed from the Config and Params tables:

And
Delete From..
WHERE LIKE "DynamicallyUpdated"

4. Using the configurator tools, the last unloading.dt from the working database (the evening of the previous day) was loaded into the backup database and the last working configuration of the current day from the existing .cf file was loaded on top (the entire history of configuration changes is stored in separate files with version numbers)

5. In the task manager I had to disable hung 1s8 processes

6. 1c server service stopped

7. Cleared 1C cache

In my case it was renaming the folders C:\Users\Administrator\AppData\Local\1C\1сv8

C:\Users\Administrator\AppData\Roaming\1C\1CEStart

C:\Users\Administrator\AppData\Roaming\1C\1Cv82

C:\Users\Administrator\AppData\Roaming\1C\1Cv8

8. Server service started

9. After clearing the cache, the window with a list of databases when starting 1C is empty, so we add an existing working server database

10. The configurator has opened. Just in case, we upload the working database in the current “broken” state to .dt and close the configurator

11. Launch SQL Server Management Studio and use a query to clear the Config table in the working database and overwrite it with the contents of a similar table from reserve bases s:

Delete From..

INSERT INTO .. ​​SELECT * FROM ..

For the authors of the materials used (see links above), after the actions taken, the functionality of the database was restored. In my case, at the current stage the error remained; it was not possible to open the database window in the configurator. Having compared the number of records in the Params tables of the working and backup databases, I came to the conclusion that it was worth trying to overwrite it too:

Delete From..

INSERT INTO .. ​​SELECT * FROM ..

After which I was able to launch the configurator and open the configuration window. Just in case, I uploaded it in the current state to .dt and loaded the latest working configuration of the current day on top.

12. Disable session start blocking and enter enterprise mode

Operation has been fully restored, no data has been lost.

13. Turn off the blocking of scheduled tasks.

One of many options for solving the error “The integrity of the configuration structure is violated.”
If you happen to encounter this error, definitely contact a 1C specialist. There are many possible solutions, but depending on the situation and the source of the problem, the solutions are completely different.

I bring to your attention one of these situations.
Description of the task:
The configuration update occurred automatically. When starting the 1C configurator mode, we receive the message “The integrity of the configuration structure has been violated.” During auto-update, the vendor configuration could not be updated correctly. Running in user mode gives an error referring to the module in the configuration.
First, you need to clear the cache. In Windows 7 OS there is C:\Users\Administrator\AppData\Roaming\1C\1Cv82 and C:\Users\Administrator\AppData\Local\1C\1Cv82 (Win7x64). After clearing the 1C cache, start in configurator mode. When I try to open the 1C configuration it crashes. Upload the information base to a backup file. Testing and fixing doesn't help. The file database check utility says there are no errors. Menu items for loading, uploading configuration, support, etc. without an open configuration they are not active. Saving the data configuration is available - this means that the data is not destroyed, which is the main thing..
Also, from the configurator to user mode in debugging mode it may start, or perhaps not, this does not affect the situation.
Trying to load the infobase into SQL will not lead to a positive result.

And then the thought arises that it would be possible to give up on the database... recover from an ancient backup, if there is one... and strain to restore the data manually.

Solution:
1. A clean configuration of the same version is required - working.
2. Clear the cache completely (indicated above).
3. Launch a clean database in configurator mode and open the configuration. At the same time, 1C creates its cache in C:\Users\Administrator\AppData\Local\1C\1Cv82 (a set of files and folders in the folder with the configuration ID.) We also need a cache in C:\Users\Administrator\AppData\Roaming\1C \1Cv82. You can simply rename the folder data after closing 1C.
4. Launch our non-working database in configurator mode and look at the cache. And as a result, we have two folders with configuration IDs (Alive and Dead).
5. Close everything and replace the cache of the dead conf with a live one completely. Those. delete the current one and replace it with the previously renamed folder.
6. We launch a non-working database in configurator mode AND HERE is the first success - the configuration tree is open, sections of the configuration management menu are active.
7. Go to support management and remove support completely. save, update. You can update it via a file with the working database configuration.
8. Delete the cache completely.
9. We launch a non-working database in configurator mode, try to open the configuration - everything opens, there are no errors.
10. Launch 1C. Everything is available. The data is in place.

Here is another rescue option proposed by infostar user Tavalik:

1. "Configuration" - "Database configuration" - "Return to database configuration"
2. "Configuration" - "Update database configuration"

“A violation of system integrity has been detected,” many users saw this error when logging into 1C. The error is caused by the fact that in December 2017, 1C released platforms with versions 8.3.10.2699 and 8.3.11.2899, in which they introduced a mechanism for checking the legality of the program.

If the version of your 1C platform is higher than 8.3.10.2699 or 8.3.11.2899, then when working with file database data, you will most likely receive the error “A violation of system integrity has been detected.” This error occurs even if you have a licensed version of 1C.

Why does the “System integrity violation detected” error occur?

Let's figure out why the error occurs. The 1C legality verification mechanism is built on the following principle. When you start 1C and enter the database, the program makes several checks:

• backbas.dll file changed (checksum is checked)
• are emulators installed?
• presence in the registry of entries from emulators

If an illegal version is detected (perhaps simply incorrect installed program) 1C gives an error and gives you the choice of “Shut down” or “Restart” 1C.

When viewing details no additional information we won't get it.

Here users begin to panic and frantically begin calling their system administrators. Nothing bad happened. Your base is safe and sound. No amount of testing and correction, as well as programs for restoring 1C databases, will help. This error has nothing to do with the 1C database.

The error is issued when an illegal version of 1C is detected or key emulators are installed. You may have a licensed version, but most likely, before purchasing a license, you used an unlicensed version and did not remove it or traces of it remained in the system.

How to get rid of the “System integrity violation detected” error

There are several ways to overcome this error.

Roll back the version of 1C:Enterprise to an earlier one. Latest versions that work without checking the backbas.dll file and emulators 8.3.10.2667 And 8.3.11.2867 . This solution is temporary, because... sooner or later a configuration will come out that will not work in these versions.

Uninstall the HASP emulator. There are many emulators, so it’s difficult to write universal instructions for their removal. You can try the following steps:

1. Find and delete the VUsb.sys and vusbbus.sys files
2. Run the commands in command line on behalf of the Administrator:
   loaddrv.exe -stop haspflt
   loaddrv.exe -remove haspflt
   del %systemroot%\system32\drivers\haspflt.sys
   It is recommended to also delete the registry keys HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\haspflt\
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Emulato r
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Emu

Well, as a last resort, rbc_icp patcher (Integrity Check Patcher). if you have license key for 1C, and USB connectors are vital for you, then you can use the illegal method. This patch disables the system integrity check in latest versions 1C:Enterprises where it is implemented.

The patch changes the following files:

• backbas.dll (unipatch 1c8_UP.exe is used)
• frntend.dll (disable integrity check in thick client)
• mngcln.dll (disable integrity check in thin client)

There is also the option of illegally bypassing the check. Using any hex editor, open the file backend.dll (if you have version 8.1) or backbas.dll (if you have version 8.2,8.3) from the bin directory in the directory with 1C installed, look for the HEX values: 100000FFD085C00F8208F8FEFF0F8416 and replace 85 with 31.

The information at the end of the article is provided for informational purposes only and does not encourage illegal actions!

UPD. 01/15/2019

Script to remove VUSBBUS and HASPFLT
Code: