Debugging Using MxVDev™ and Visual C++

Using MxVDev and Microsoft Visual C++ together to debug SUT applications gives developers a huge advantage at developing and debugging their application. MxVDev can be used to test requirements, to provide a visual picture of the state of the executing application, to setup inputs to catch a bug in the code, or to watch changing outputs. Microsoft Visual C++ provides a fully featured development environment to debug and develop SUTs while they are being tested and subjected to inputs and test cases by MxVDev.

Setting Up Your Microsoft Visual Studio Project to Launch and Load MxV Projects

All SIL projects created by MxVDev include a Visual C++ solution and project. The Visual C++ solution (.sln) is usually located in the same folder as the MxV project. The Visual C++ project is already set up to launch and load the MxV project when the debugger is started (Debug‑>Start Debugging). If the project settings get lost and need to be set up again, see Visual Studio and MxVDev.

Enabling Just-In-Time Debugging with Microsoft Visual C++

It is strongly recommended that Just-In-Time debugging be enabled in Microsoft Visual C++. Just-In-Time debugging is a feature that launches the Visual Studio debugger automatically when a program, running outside Visual Studio, encounters a fatal error. Just-In-Time debugging enables you to examine the error before the application is terminated by the operating system. The Visual Studio debugger does not need to be running when the error occurs. If an error occurs while Just-In-Time debugging is enabled, a dialog box opens, asking if you want to debug the program and which debugger you want to use.

To enable/disable Just-In-Time debugging with Visual C++ 2003 or later:

1.Select Tools->Options from the Visual Studio menu bar.

2.In the Options dialog box, select the Debugging folder.

3.In the Debugging folder, select the Just-In-Time page.

4.In the Enable Just-In-Time debugging of these types of code box, select or clear the relevant code types. For debugging C code, as is used in the MxVMC, select Native.

MSVC-native

5.Click OK.

Debugging SUT Applications Using Microsoft Visual C++ Debugger

The SUT application must be built with no errors before debugging the application is possible. Start the debugger by selecting Start Debugging under the Debug menu (or by pressing the F5 under VC++). This launches the debugger, which launches MxVDev, loads the MxV project, and attaches the SUT to MxRTE.exe. Visual C++ debugger might display the following warning message:

Debugging information for 'MxRTE.exe' cannot be found or does not match. Binary was not built with debug information. Do you want to continue debugging?

This warning message can be ignored by pressing the Yes button (checking “Don’t show this dialog again” and then pressing the Yes button will stop this warning message from popping every time a SUT is being debugged).

Breakpoints can be placed anywhere in the SUT code (such as SUT_Init(), SUT_Tick(), and MxVOpen()). Once a breakpoint is hit, the Visual C++ debugger pauses the execution of the SUT at that line of code and MxVDev pauses the executing scenario waiting for the SUT to continue running. While debugging the SUT, users have the full advantage of using MxVDev to see the actual state of the application by monitoring the inputs and outputs and have the fully featured debugger to place breakpoints, watch variables, step through the SUT code, and use the memory window.

Breakpoint Causes Disassembly

If you experience an issue when debugging where hitting a breakpoint produces a disassembly rather than the source code, you must change the Debugger Type for the Visual Studio project as follows:

1. In Visual Studio, right-click the project in the Solution Explorer and select Properties.

2. Select Debugging on the left hand side of the dialog box.

3. Change the Debugger Type to Native only. See Visual Studio and MxVDev.

Related Topics:

Visual Studio and MxVDev

Debugging Access Violations and Other Memory Overruns

MxVMC C/C++ API

Timing and Performance Considerations for Co-Simulation

Troubleshooting