8, there is a need (as discussed below) for a significant reworking of the debugging procedure. This was reflected in version 8.3.7.1759. Firstly, a universal interface was created for this procedure, and secondly, this change ensures the further development of the program itself. After all, now you can work with debugging not only through the Configurator, but also using Development Tools. Let's look at how to enable debugging on the 1C server starting from the new version.

Using the new protocol

The previous debugger, which was implemented in previous versions, managed client and server applications using the TCP/IP protocol.

Currently, the use of such a protocol has begun to limit the access of the 1C:Enterprise program to the Internet and has caused inconvenience for the operation of mobile applications.

Therefore, for free access to information bases that may be located outside the local network, the flexible HTTP protocol has now been adopted.

New architecture

Previously, when performing configuration debugging, an employee had to connect to the information base. To do this, it was necessary to give him administrator rights.

In the new version, there is no need to directly connect to the databases - it is enough to simply have the same database as the client. And you can load it from a file.

Mobile applications

Using the HTTP protocol, it is now possible to debug server data, client data, and applications.

Other changes

With the new version, it is possible to change values ​​for local variables in the debugging procedure; a new quick view window has been implemented for this purpose.

The calculation mode has been changed to asynchronous, allowing you to continue working without waiting for results.

Debugger in Development Tools

Interaction with the new procedure is carried out in a specially developed universal software interface. On the one hand, this interface is used by the Configurator. On the other hand, it is implemented in the new 1C:Enterprise Development Tools environment.

What does it look like now

After changing the program, the procedure occurs according to the following scenario:

Now it involves not only the debugger and items, as was previously the case. Now an additional element has been introduced into the chain - Server.

Not only is it added - it serves as the main element of information exchange between the debugger and objects. And the exchange itself occurs through messages lined up in a queue.

And since this exchange is carried out via the HTTP protocol, it now does not matter where exactly the data may be located.

Calls to the server are formed from the debugger and objects in the form of additional connection requests. When they appear, appropriate responses are sent to them.

Enable debugging in different scenarios

For the application developer, there have been no changes. The significant difference is that the new mechanism must be enabled. After all, it is now disabled by default.

Let's look at what happens when the mode starts if we choose one of two scenarios.

File script

At the beginning of the file version, you must specify in the configuration settings the use of a new mechanism - “Debugging via HTTP protocol”.

Then the Configurator will automatically suggest using a local server. This condition must be accepted and the program restarted in Configurator mode.

After this, the newly launched Configurator will save the new method we have chosen during the next session. But for the same information base. Therefore, when accessing another infobase, it also needs to be enabled.

The enabled mechanism will now automatically launch the Debugger Server, which is a special application dbgs.exe. It is reflected in the Task Manager window.

The value of the ownerPID parameter will correspond to the ID of the application that is bound to it.

When you start a debugging session through the Configurator, the server connection will occur automatically. And the connected objects will be reflected in it.

If the 1C program was activated without the new mechanism, then you will need to enable debugging on the 1C server manually. Only now you will need to specify the server address:

Go to Service - Options

It is located in the item settings:

Go to Connection - Settings

When using a file script with several databases at the same time, you need to take into account an important nuance - each of the Configurators (with the HTTP mechanism enabled) sends its own Server:

Therefore, if several Configurators are open, then to connect the Client you need to specify the correct one.

Client-server scenario

Debugging on a 1C server using a client-server scenario, as in the previous case, begins by launching the mode. This specifies the use of the new HTTP mechanism. This is done this way:

ragent.exe -debug -http

When it starts, the debugger automatically starts behind it.

The value of the ownerPID parameter will correspond to the identification number of the 1C cluster manager.

The program will generate a proposal to use the cluster debug server now (and not a local one as in the previous scenario). We agree and restart it.

In the future, everything will go like a file script. Only when you start the Server Database Configurator will the local debugger server no longer start.

We hope that our publication helped you figure out the problem of how to enable debugging on a 1C server.

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 working 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.

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!

In order to be able to debug server procedures, you need to set the flags in the “Service->Parameters” form of the configurator:

Debugging on the application server

This is described in the documentation:

Book “1C:Enterprise 8.1. Configuration and administration"

Chapter 18. Configuration Tools

Debugger and performance measurements

"Debugging code on the server

To install debug mode, you should start the 1C:Enterprise server with the /Debug command line switch (ragent.exe /debug)."

The server agent startup keys are described in the book:

"1C:Enterprise 8.1. Client-server. Features of installation and use"

"Running the server agent as a service

If, when installing a server cluster, you selected the option of launching the central server agent as a service, then this service will be launched automatically during the installation process and will also be launched when the operating system starts.

If the central server agent was installed as an application, then it is possible to register the service manually and then launch it.

Service registration is performed with the following command:

Ragent.exe -instsrvc -usr<пользователь>-pwd<пароль>-port<порт>-range<диапазоны>-seclev<уровень>-debug | -rmsrvc | -start | -stop

Instsrvc – registering the cluster agent as a Windows service. If ragent.exe is launched with this key, it registers in the list of Windows services and exits. Not compatible with -srvc, -rmsrvc switches;

Usr<имя пользователя>

Pwd<пароль пользователя>– the name and password of the Windows user under whose name ragent.exe should be launched as a Windows service. Can only be used in conjunction with the -instsrvc switch when registering ragent.exe as a Windows service;

Port<порт>– number of the main port of the cluster agent. This port is used by the cluster console to access the central server. The cluster agent port is also specified as the working server IP port;

Range<диапазоны>– IP port ranges for dynamic selection. From these, service ports of cluster processes are selected if it is impossible to select them from the settings of the corresponding working server. Default: 1560-1591. Example values<диапазоны>: "45:49", "45:67,70:72,77:90";

Seclev<уровень>– security level of the cluster agent process. Determines the security level of connections established with the ragent.exe process.<уровень>can take the following values: 0 (default) connections are not secure, 1 – secure connections only for the duration of user authentication, 2 – permanently secure connections.;

Rmsrvc – unregisters the cluster agent as a Windows service. If ragent.exe is launched with this key, then it cancels its registration in the list of Windows services and exits. Not compatible with -srvc, -daemon, -instsrvc switches.

Start - launch ragent.exe registered as a Windows service. Launches ragent.exe, previously registered as a Windows service, and then exits;

Stop - stop ragent.exe registered and running as a Windows service. Stops ragent.exe, previously registered and running as a Windows service, and then exits;

Debug - launching a server cluster in configuration debugging mode. "

Thus, if the 1C:Enterprise server was launched as a service and for some reason it should also be launched as a service in debug mode, you must first unregister the service (the -rmsrvc key), and then re-register the service with the -debug key.

Obviously, a similar effect can be achieved in other ways, for example, by directly editing the Windows registry. To do this, you should probably consult your Windows documentation.

Works only when the "-debug" key is set in the registry. In all other cases it doesn't work for some reason.

"ImagePath"=

was "F:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "F:\Program Files\1cv81\server"

set "F:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d "F:\Program Files\1cv81\server"

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 specify 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 are of interest to 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.