These are the restrictions in local and remote debugging in the IDE:
- You might experience a slight delay when initiating a debug session for a COBOL project. This is caused by the out-of-date
checking to determine whether the project requires a rebuild.
- When debugging
.gnt code on early builds of Windows 10 and Windows Server 2016, execution fails to stop at COBOL breakpoints. To resolve this,
you should install the most recent Windows updates for your operating system, as this problem is only known to be present
with the earlier versions.
- When there are multiple COBOL programs in your project that perform a COPY… REPLACING in a copybook, the Autos window only
uses the replacing values found in the first COBOL program.
- The debugger ignores a COBOL watchpoint that is hit if there is no statement following the statement that modifies the data
on which that watchpoint is set.
- The debugger does not fully support native OO programs. For example, QuickWatch or entering data names in the Watch window
displays an error.
- If your application receives a raceOnRCWCleanup (managed code debugger assistant) while debugging, this could be because your
WPF application is not performing any closed/shutdown handling. To resolve this, add the following method in the App.xaml.cbl
source:
method-id OnExit protected override.
procedure division using by value e as type ExitEventArgs.
invoke super::OnExit(e)
*> Insert any other closedown code before the stop run statement.
stop run.
end method.
For more information see
http://msdn.microsoft.com/en-us/library/ms743714.aspx#Application_Shutdown
- It is not possible to add a watch on a local variable.
- A core dump file is not created for a stack overflow condition.
- If your project includes more than one program and you hover data items in a program that is not the current program being
debugged, you may get the wrong values in the debug tooltip or no debug tooltip at all. This is because the context is the
current program being debugged. This is expected and is the default Visual Studio behavior.
To point which program is the current context:
- Start debugging your project and step into the code.
- Click
to display the call stack.
The program being debugged is indicated by a yellow arrow. This program is also the current context.
- Continue stepping the code till the call stack list is populated with the other programs in your application.
- Double-click the program you wish to query in the call stack list.
This adds a green arrow in front of the program in the list to indicate it is the current context.
- In the editor, open the program or the copybook which contains a reference to the item you want to query.
- Hover a data item.
The debug tooltip should display the correct value.
- When debugging an application compiled for either x64 or Any CPU, Visual Studio hangs if a breakpoint within a DateTimePicker
event handler is reached. This is a known Microsoft problem. To work around this issue, configure the application as a 32-bit
application while debugging.