Debugging in Visual Studio (Known Issues)

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 or on parameters within a parameterized section.
• 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:

  1. Start debugging your project and step into the code.
  2. Click Debug > Call Stack to display the call stack.

     The program being debugged is indicated by a yellow arrow. This program is also the current context.

  3. Continue stepping the code till the call stack list is populated with the other programs in your application.
  4. 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.

  5. In the editor, open the program or the copybook which contains a reference to the item you want to query.
  6. 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.
• The Watch window supports normal numeric arithmetic expression with intrinsic functions and the single use of alphanumeric intrinsic functions. The following expressions are not supported - logical operators such as b-and and b-or; ISO2002 user defined methods; inline method invokes, and intrinsic functions which are evaluated at compile time. See Watch Window for details.
• Whilst debugging, variables defined with the DYNAMIC LENGTH clause cannot be expanded beyond their current length; that is, the length at the time of the step being executed.