LabWindows™/CVI™ 2017 Runs Slower Within Debug Mode in Windows 10

Issue Details

I upgraded from a previous version of LabWindows/CVI running on a Windows 7 pc to LabWindows/CVI 2017 on a Windows 10. During the debugging process, I am seeing a slowdown when using the step over command on Windows 10 compared to Windows 7. The slowdown does not occur when using Release mode.

Solution

There are multiple reasons behind the possible slowdown during the debugging process of the LabWindows/CVI application. There are some recommendations to improve the debugging time:

• Use the latest version of LabWindows/CVI available for Windows 10 (version 2020). There are several improvements and bug fixes from one version to another. Using the latest version will ensure all those bug fixes are included. Improvements have been seen when using a newer version of LabWindows/CVI when compared to version 2017 on Windows 10.
• Resource tracking takes time. It is turned on by default in Extended debugging mode. You can use Standard mode instead if you do not need this feature. In LabWindows/CVI 2017, the development environment may slow down or hang when performing extended debugging with the Resource Tracking window.
• Watchpoints set to "break on change". Machines provide hardware support for a limited number of them and that is fast. If you have too many or if you are watching something larger than 4 byte (32-bit) or 8 bytes (64-bit), then they will be very slow. Watchpoints set to "update continuously" are also slow and should be avoided.
• One option is to run outside of the debugger, the run-time checking will still catch run-time errors and offer to debug the executable at that point (a dialog is shown and offers to break into/debug the executable from then on). It is not as convenient as doing everything within the same CVI instance but might serve as a workaround. Some ideas on how to make this more convenient:
  • Exchange the keyboard shortcuts for debugging (Shift+F5) and running outside the debugger (Ctrl+F5) under Options >> Change Shortcut Keys. (But Ctrl+F5 doesn't automatically rebuild the executable).
  • Retain the original shortcuts. Start the program with debugging (Shift+F5). When it's taking too long, break into the program and detach with Run >> Detach from Process. The program continues to run outside the debugger.
  • Reattach to a running program with Run >> Attach to Process... You can resume debugging as you normally would, set breakpoints, etc. Or detach from the process again.
  • Enable break on library errors to get notified when a library function returns an error (This option has the same effect as Run >> Break On >> Library Errors but it takes effect even when running outside or detached from the debugger.):

    #include <utility.h>
    SetBreakOnLibraryErrors(1);

  • When running outside or detached from the debugger, CVI still traps run-time errors when you're using the Standard or Extended debugging levels. The executable displays a dialog and offers to break into/attach to a debugger. You can then inspect your program's variables, etc. If the run-time error is non-fatal, you can step over it and through the program. You can continue running or detach the debugger.
  • When running outside or detached from the debugger, breakpoints won't work. But you can simulate them by forcing a non-fatal run-time error. One way to force a non-fatal run-time error is:

static void breakpoint()
{
   char c, *ptr = &c;
   ptr+2; // <- non-fatal error because pointer arithmetic is out of bounds
}

Additional Information

Debugging should be faster in No-runtime-checking debugging mode because the compiler does not check pointer arithmetic, function return values, etc. In general, this debugging mode is not recommended because you lose so many useful checks.