The task of a 1C developer is not only to write code, but also to track and correct errors, build an optimal command execution algorithm and optimize the speed of work, that is, debugging. It is difficult to do this without using the functionality of the built-in debugger of server procedures.
Initially, debugging mode is disabled on 1C servers, so the developer will have to do simple manipulations with the settings in order to be able to thoroughly check the code.
Enabling debugging mode on the server for the 1C platform version 8.2 and higher
The algorithm for enabling debugging is quite simple. It does not assume in-depth knowledge of operating system architecture and 1C administration. However, you should still be very careful, because debugging work is performed directly on the server and with administrator rights. Therefore, if you do not have thorough knowledge, strictly follow the algorithm of actions without improvisation:
- Stop the 1C:Enterprise Server Agent service through Server Manager. If the setup takes place on a production server, then you should take care in advance about the absence of 1C users in the database;
- Launch the system registry editor by clicking “Start” - “Run” or the keyboard shortcut “Win” + “R”. In the window that opens, enter the line “regedit”;
- In the registry you need to find the item;
- Among the parameters, find “ImagePath” and change it by adding “-debug” to the existing value with a space at the end;
- Through the Server Manager, start the service that was stopped - “1C:Enterprise Server Agent”.
Enabling debugging mode on the server for 1C version 8.1
If you need to enable debugging mode on platform 8.1, the algorithm of actions remains virtually unchanged. The only change is the location of the "ImagePath" path parameter. In version 8.1 it is located in the section.
1C developers advise enabling debugging mode exclusively for test servers, where the code should be debugged. The reason for this recommendation is because of the performance impact that occurs when debugging is enabled on the server. If you have many users or the server power leaves much to be desired, take this advice carefully so that debugging does not have negative consequences.
Implemented in version 8.3.7.1759.
We have significantly redesigned the debugging mechanism. There were several reasons for this. First, we wanted to give you the ability to debug every application available today. Secondly, the previous debugger architecture required changes in order to keep up with current trends and accommodate future development. Thirdly, a universal debugging interface was needed, with which not only the 1C:Enterprise configurator, but also .
Main advantages
So that you can imagine the scope of the changes we have made, we will briefly list the main advantages of the new mechanism.
HTTP Debugging
The previous debugging mechanism was based on the fact that the debugger, implemented in the 1C:Enterprise configurator, directly interacted with debug items (client and server applications). This interaction was carried out using the TCP/IP protocol.
However, with the release of 1C:Enterprise applications on the Internet, and especially with the advent of mobile applications, this approach has become a source of limitations and inconvenience. The TCP/IP protocol does not always allow the debugger to “reach” the items being debugged. After all, they may be located outside the local network in which the debugger is running.
Therefore, in the new mechanism, we chose the more “ubiquitous” HTTP protocol as the transport protocol, which, by the way, is also used by client applications to connect to information databases.
Modern debugging architecture
A feature of the previous debugging mechanism was the need to connect to the infobase using the configurator. As a result, the developer debugging had full access to all administrative functions.
The new debugging mechanism no longer requires a connection to the infobase being debugged. The main thing that the debugger now needs is the same configuration that works for clients. To obtain it, there is no need to connect to the infobase being debugged. You can load it, for example, from a file.
Debugging mobile applications
Thanks to the use of the HTTP protocol, it has become possible to debug applications executed by the mobile platform. Moreover, you can debug any contexts: client, server, as well as background jobs.
Now, during debugging, you can change the values of any writable variables. To quickly view and change local variables, we have implemented a separate window. And the calculation of expressions displayed by the debugger is now performed in asynchronous mode.
Debugging in Development Tools
When creating a new debugging mechanism, we implemented a new, universal software interface for interacting with it. This interface is used by the 1C:Enterprise configurator, and the same interface is now used by the new development environment. Thus, all debugging capabilities are now available when working in .
Debugging process architecture
The new debugging architecture looks like this:
Debugging involves a debugger, debugging items, and a new element - debug server.
There is no direct transfer of information between the debugger and debug items. All interaction is organized through the debugging server. This is the main element of the mechanism. The debugging server has a message queue through which the debugger and debug items pass information to each other.
Both the debugger itself and the debug items communicate with the debug server via HTTP. So now it doesn't matter where these debugging items are located.
Interaction with the debug server is initiated by the debugger and debug items. For this purpose, additional connections are organized. Their main purpose is to find out if information has appeared for them on the debug server. And if it appears, get this information.
Thus, the interaction is one-sided. Information is constantly transferred from the debug server to the debugger, and to debugging objects.
Identification of information bases
In the previous mechanism, a connection string was used to identify infobases. This solution in some cases caused difficulties in matching debugging items and the configurator. Because, firstly, it was case sensitive, and secondly, when debugging some contexts, the platform generated the connection string automatically. And it did not always coincide with the one you specified when connecting the infobase in the configurator. Finding and correcting such situations complicated the debugging process.
In the new mechanism we got rid of the connection string. Now we use infobase identifier. In the file infobase, such an identifier is generated the first time a client connection is established. In the server infobase, the infobase registration identifier in the cluster is used as such an identifier.
A nice additional point here is that we have retained the old debugging mechanism in the platform for now (it may be excluded in the future). And you can use it if you wish, or if necessary. So we have modified the old mechanism, and now it also uses the infobase identifier, and not the connection string.
Typical Debugging Scenarios
From an application developer's perspective, typical debugging scenarios have not changed. The only significant difference is that the new debugging mechanism must be enabled. Because by default it is disabled.
Regardless, it makes sense to become familiar with what happens now when you run debugging. Because it may be useful to you in some non-standard work scenarios.
File option
Before you start debugging in the file version, you need to indicate in the configurator settings that you want to use the new debugging mechanism - “ HTTP Debugging».
In this case, the configurator will automatically prompt you to use a local debugging server. You need to agree with this and restart the configurator.
The debugging method you set is saved between configurator sessions, but it is stored in the context of infobases. Therefore, for another infobase you will need to enable it again.
Now, when you start the configurator, or when you restart it, the platform will automatically launch the debugging server. This is a separate application, dbgs.exe. You can see it in the task manager.
The ownerPID parameter specifies the identifier of the application that owns this debugging server. In this case, this is the 1C:Enterprise configurator.
Now, if you launch a 1C:Enterprise debugging session from the configurator, it will automatically connect to the debugging server, and in the configurator you will see the connected debugging items.
If the 1C:Enterprise session was launched without debugging, then, as before, you can connect it to the debugger. Only now you need to specify the debug server address:
You can find this address from the debugging items settings:
There is one unusual point associated with working with several file databases at once. In the file version, each configurator with http debugging enabled launches its own copy of the debug server on different ports:
Therefore, if you have several configurators open at once, then to connect the client application to the debugger you need to select the correct one.
Client-server option
Before you start debugging in the client-server version, you need, as before, to start the 1C:Enterprise server in debugging mode, but indicate that the new HTTP mechanism will be used for debugging. For example, like this:
ragent.exe -debug -http
When the server is started this way, the debugging server will also be started.
The ownerPID parameter will indicate the identifier of the 1C:Enterprise cluster manager.
Now in the configurator settings, as in the case of the file database, you need to indicate that you want to use the new debugging mechanism - “ HTTP Debugging».
In this case, the configurator will automatically prompt you to use the cluster debugging server, and not the local server. You need to agree with this and restart the configurator.
Connecting Debugging Items
When you start debug sessions from the configurator, applications automatically connect debug items (both client and server) to the debug server.
At the same time, as before, you have the opportunity to configure the configurator to automatically connect debugging items, regardless of how they were launched. Now these possibilities have become much richer.
Firstly, the platform now offers you all possible debugging items to choose from.
And secondly, another, more subtle way of setting has appeared. This is the use of pre-created selections.
You can use such selections both when connecting debug items and to view available debug items.
In the selection, in addition to the debugging items themselves, you can specify specific users whose sessions interest you, and also, if data separation is used, indicate the area of the infobase that will be debugged.
Changing variables, object properties, and asynchronously evaluating expressions
The new debugging mechanism allows you to change variable values while debugging. In the previous mechanism there was no such possibility.
For convenient viewing and changing local variables, which seems to be the most common task, we have implemented the “ Local variables».
Outwardly, it is very similar to the “Scoreboard” you are used to. But, firstly, this window is already automatically filled with all local variables, and secondly, you can now change the values of the variables.
You can change the values of primitive types directly in the cell " Meaning»:
And to change other values, you can use the expression input window:
A nice bonus is that the contextual tooltip is fully functional in this window.
In exactly the same way, you can change the values of any (not only local) variables and writable properties. In the expression calculation window (which is called by the Shift+F9 command), you can change the values of variables both in the “Value” cell and using a separate dialog.
By the way, the expression calculation itself is now performed asynchronously. This means that the configurator orders the calculation of the debugging item. And for some time this calculation is expected on the server. If the calculation is completed, the results are immediately sent to the configurator. If the calculation is carried out for a long time, then the results of these calculations arrive asynchronously to the configurator later. This approach allows you not to wait for lengthy calculations in the configurator and continue your work.
This article talks about how to enable debugging on a 1C server 8.1, 8.2 and 8.3 in Windows and Ubuntu operating systems.
In addition, I note that this article is part of a small series of articles about debugging in 1C:
- How to enable debugging on a 1C server
Enable debugging on the 1C server in Windows
Launch the registry editor by running the regedit command (using Win+R or Start->Run).
You can read more about HTTP debugging and the debug server in the next article in the series.
Enable debugging on the 1C server in Ubuntu
First we install the server:
sudo service srv1cv83 stop
After this, open the /etc/init.d/srv1cv83 file as superuser and find the line in it:
And we bring it to this form:
Then we start the server again:
sudo service srv1cv83 start
In the configurator on the client machine, go to “Settings” -> “Launch 1C:Enterprise” -> “Advanced” and enable two items:
- "Set debug enable mode"
- "Start debugging at startup"
You can read about how to install a 1C server on Ubuntu 16.04/18.04.
That's all, I hope this article was useful to you. Let me also remind you about other articles in the series about debugging in 1C; links to them can be found at the beginning of this article.
How to start debugging on a 1C server...
By default, when using the 1C:Enterprise client-server architecture, the 1C code debugging mode works only on the client side. Server procedures and functions are not visible to the client machine.
To enable the use of debugging on the 1C server, you must perform the following steps:
1. Find and stop the “1C:Enterprise Server Agent 8.3” service in the service manager (for version 8.3).
2. Open the system registry editor. You can use the command line or the Start - Run... menu tool and the command regedit.
3. Find the branch in the registry:
- For version 1C 8.1
- For version 1C 8.2
- For version 1C 8.3
4. Change the ImagePath property, add the “-debug” directive to the end of the line. You will get the following property line: “C:\Program Files (x86)\1cv8\8.3.6.2152\bin\ragent.exe” -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d “C:\Program Files (x86)\1cv8\srvinfo" –debug
After this, the 1C server code can be safely checked with a debugger and breakpoints can be set wherever required.
18.10.2016
Debugging on a 1C server (8.2, 8.3...)
If the 1C database is running in a client-server version, the code debugging mode on the server side is disabled. Therefore, it will not be possible to see step by step what happens when executing a function or procedure. To enable server-side debugging, you need to follow a few simple steps.
Enable debugging on the 1C:Enterprise server 8.2, 8.3
The first thing you need to do is stop the 1C:Enterprise server service. Go to "Start - Run" (or the keyboard shortcut "Windows + R"), write "services.msc" (of course you need to open Windows services management from the Administrator)After stopping, open the Windows registry editor ("Start - Run" (or the keyboard shortcut "Windows + R") and write "regedit"), and find the branch with the name "" or "" depending on platform version
We are interested in the registry key named "ImagePath". Add "-debug" to the end of the key value. This means that the debugging mode on the 1C server side is activated.
Was: "C:\Program Files\1cv8\8.3.6.2530\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"
Became: "C:\Program Files\1cv8\8.3.6.2530\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug
Save and start the 1C service. All is ready! Happy debugging!
