Stepping into C++ DLL code from TestStand 4.0

[freak]

I recently upgraded to TestStand 4.0 and and Measurement studio 8.1.1 and cannot step into my code from TestStand for debugging. Under TestStand 3.5, I was able to step into the same C++ (DLL) code without any issues. In TestStand 4.0, step into behaves like a step over rather than step into. has anyone seen this problem? Any ideas?

Note: This question is also posted to the Measurement Studio for C++ forum.

[RayFarmer]

Hi,

I dont believe there is any difference between 3.5 and 4.0 when it comes to debugging of a DLL.

Check out the link

http://digital.ni.com/public.nsf/websearch/52f5bb7ae7f5a409862569ee0073ac53?opendocument

for setting up TestStand.

Regards

Ray Farmer

[drohacek]

For this response, I assume that you are trying to step into unmanaged C/C++ DLL code, using Visual Studio 2003. Please let me know if these assumptions are incorrect.

TestStand integration with Visual Studio did change in TestStand 4.0. See pages 7 & 8 of the Release Notes for more information. You can access the release notes by going to Start>>All Programs>>National Instruments>>TestStand 4.0>>Online Help>>Manuals>>TestStand Release Notes.

The short of it is that if you use Visual Studio 2005, you should be able to step into your code just as you did with prior versions of TestStand. If you use Visual Studio 2003, you need to attach the debugger manually.

To attach the debugger manually, launch Visual Studio 2003, choose Tools>>Processes, choose SeqEdit.exe from the list of processes, click Attach, select Native, click OK, and click Close. At this point, you should be able to set breakpoints in your C/C++ DLL code and those breakpoints should be hit when execution reaches them.

I apologize for any inconvenience this causes you. Visual Studio integration is a tricky business. It is far more difficult for us than CVI or LabVIEW integration (because we have far greater influence over the APIs and functionality of those ADEs than we have over Visual Studio). We do have, on our list of possible future deveopment work, an item to better address Visual Studio integration in a future version of TestStand.

Will either of these two workarounds (use VS2005 or attach manually) meet your needs, at least minimally?

On a scale of 1 to 5, with 5 being most important, how important is it to you to be able to step directly into C/C++ code using Visual Studio 2003?

David Rohacek

National Instruments

Note: I don't think this applies to you because you mentioned C/C++ DLLs, but I want to point out that you cannot attach the Visual Studio 2003 debugger for managed code to the TestStand 4.0 Sequence Editor. This is because the TestStand 4.0 Sequence Editor uses .NET 2.0 and the Visual Studio 2003 managed debugger cannot debug

Message Edited by drohacek on 06-26-2007 07:46 AM

Message Edited by drohacek on 06-26-2007 07:47 AM

[freak]

David,

Thanks for the explanation. I am using unmanaged c++, and I also had the .NET framework 2.0 installed prior to installing TestStand 4.0. I tried to manually attach the debugger without success. I don't think there is any chance of getting VS2005 anytime soon. The release notes state the following: 'You cannot use Microsoft Visual Studio 2003 to debug managed code in the
TestStand process if TestStand loads the .NET Framework 2.0. Instead, you must use Microsoft Visual Studio 2005.'

Does the .NET framework get loaded only when executing managed code? what if it is used by other applications on my

system?

[Scott_Richardson]

David might not be able to respond, so maybe I can pick up where he left off. The .NET 2.0 framework will be automatically loaded into the process if you are using the TestStand 4.0 Sequence Editor, or if you are using a operator interface that is uses the new Insertion Palette or the Variables View controls, or if you call a .NET code module using the .NET Adapter. Having the .NET 2.0 framework in memory should not prevent you from manually debugging an application using Visual Studio 2003, as long as you attach using native debugging (not managed or both). So is your application that you are attaching to the TestStand 4.0 Sequence Editor? Are you sure that you attached using only native debugging?

[freak]

here is the step by step sequence of actions I take to attempt to step into my code:

- open visual studio 2003
- load my project
- rebuild it
- open the cpp file I want to debug and set a breakpoint
- open the teststand 4.0 sequence editor
- open the sequence file that contains calls to my code
- set a breakpoint on the first C++ adapter step that calls my dll code
- in visual studio, go to tools->debug processes and select:
 - default transport
 - seqedit.exe process
- press attach..., select native and press ok. At that point, the dll is running, the play button on the
  visual studio debug toolbar is disabled, while the pause and stop buttons are enabled. ALSO there is
  now a question mark on the breakpoint in my c++ code.
- I start the teststand sequence from the sequence editor and wait for it to break
- when the execution breaks on the C++ adapter step, I press the step into button on the sequence editor's
  debug toolbar, expecting it to step into my c++ code and instead it steps right over the sequence step.
 
Questions:
- Do I even need a breakpoint in the teststand sequence on the C++ adapter step?
- Is there anything in that procedure that I am doing wrong?

[ktietjen]

Q: Do I even need a breakpoint in the teststand sequence on the C++ adapter step?

A: No, once you have attached the debugger, whenever a debugger break point is hit it will stop.

Q: Is there anything in that procedure that I am doing wrong?

A: The steps you are taking to debug your dll sounds good (I just tried it and it works).  However, there is obviously some other problem.  The first thing to confirm is that you're building your dll with debug symbols, either in the binary or emitting them to a .pdb file (without them the debugger is unable to match up source code with the machine code in the dll and so will be unable to break).  The next thing is to confirm you are loading the correct dll (that was built with debug symbols), I'll explain how to do this later.  After that confirm that the debugger was able to load the symbols.  Next confirm that the debugger was able to match up the breakpoint that you specified in your source to a specific spot in your dll.  If all these things happen then the debugger should be able to break at the right place.

Instructions:

How to make sure that you are loading the right dll:  One of the easiest methods is to set a break point in TestStand right after the step that calls your dll.  Attach the debugger, just as you have described and press the break toolbar button (looks like a pause button).  In VS2003, select the Debug->Windows->Modules menu.  In the Modules pane sort the modules by name (you can do this by click on the 'Name' column header), find your dll and verify in the path column that this is the dll that you really wanted to load.

How to confirm that the debugger was able to load debug symbols: Using the same instructions as above, look at the Information column for the words 'Symbols loaded'.  If so then the debugger found the correct symbols.

How to confirm that the debugger was able to match the source code breakpoint to a specific spot in your dll:  Follow the above instructions and then set or view a desired breakpoint in source.  If the break point is anything other than that (unless you've set advanced options) means that there was a problem and you can hover over the breakpoint to find out more information via the tooltip.

[freak]

Thanks for the tip. My visual studio project was not setup to generate debug info and create a .pdb file.