LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

run debug executable directly

Solved!
Go to solution

Is there any reason you can't run the debug executable version of a CVI application directly, without the IDE running?

 

How about if the CVI IDE is running, but has some other project selected as the  active project?

 

I am seeing the circumstance where if I run the application in debug configuration from the IDE, it functions as expected.  If I run the same executable, but directly by double-clicking the debug executable file name, then the executable quits unexpectedly after running for a few minutes.

 

Thanks,

 

Menchar

0 Kudos
Message 1 of 7
(4,723 Views)

Hi Menchar,

 

That behavior is definitely unexpected. You should be able to run any CVI executable outside or inside the debugger, regardless of whether it's a debug or a release build. I do it all the time. Whether zero or more instances of the CVI ADE is running, or what any of those instances might doing at the time, or what projects they might have loaded (or even be debugging, for that matter) should have no effect at all.

 

It's possible that there might be some subtle timing differences that could be triggering some race condition that only manifests itself when the application is not being debugged. Does this crash happens consistently, and if so, have you narrowed it down to where it might be happening? I realize it's not a trivial thing to do when you can't use the debugger, but you could insert some message dumps near the point where it's crashing that would narrow it down.

 

Also, does the application simply disappear, or does it display a message box of some kind that could give us some additional information? If the crash happens at the top level of the program, the CVI user protection should catch it and offer to attach the debugger to it. If it happens at a lower level, I would except some general exception dialog, hopefully with a memory address (which would be helpful).

 

Luis

0 Kudos
Message 2 of 7
(4,697 Views)

Luis -

 

Thanks for the response, I appreciate it.

 

Crash happens consistently, at the same point.  No Windows exception popup, but then now that I think about it we've got the system configured to run headless normally, and I believe I defeated the exception popups.  The app just disappears.

 

I should reenable the exception popups and I bet there is some exception.  Or I should look in the Windows event log - even if the popups are defeated, the event log should capture it.

 

It is an interesting problem, isn't it.

 

I run the debug build often, you get some debugging info without trying to run the application from the IDE. 

 

It would be nice if the debug build could launch CVI - maybe a switch in the debug build options to insert CVI launch code at breakpoints.  That way you could run the application in its normal context, and if you happen to hit a BP or exception launch CVI. 

 

Can you get windows to launch CVI at an exception?  Doesn't the exception popup offer to start a debugger?

 

Menchar

 

 

0 Kudos
Message 3 of 7
(4,683 Views)
Solution
Accepted by topic author menchar

Here's the reason for the behavior I was seeing.

 

Another developer mis-used the Win32 SDK FormatMessage function.  He was concatenating his own string onto the system-supplied error message string without telling the function to allocate room in the message string (which you can easily do - the function's designed to allow this if you tell it to).

 

So, when given an error code, FormatMessage was returning a pointer to a string just large enough to hold the message it had formatted into it.  When the calling code appended to that string, it was overwriting who knows what in memory - buffer overrun.   I had also turned off the Win XP DEP (Data Execution Prevention) facility.   So the overrun was going undetected and in the stand-alone debug image was overwriting something critical because it would cause the program to terminate without an exception popup or a system event being recorded!

 

Somehow when the same image was being executed from CVI, the heap was getting allocated / managed differently such that the buffer overrun didn't cause damage.

 

CVI debug builds can watch for buffer overruns for user-defined arrays, but obviously can't do that when you overrun a system-allocated buffer.

 

So the world makes sense, after all 🙂

 

Menchar

Message 4 of 7
(4,669 Views)

Hi folks,

 

I remember I was able to start a debugbuild's exe from the windows explorer some months ago (with CVI 8.5, I guess). After running some time, a runtime error occurred - i think , it was a library error, and it was correct that this error was detected. And then CVI popped up with the respective source code, giving me the possibility to debug the program. (This question turned up some tags above).

 

Today (now using CVI 9.0) , I would  explicitely need this feature (running _dbg.exe, with CVI popping up at an error or breakpoint), but it does not work anymore; I have 9.0 and 6.0 installed in parallel, but it does not work in 6.0 neither.

 

First question : was this supposed to work anyway ? If so : must an instance of CVI be started before ? And finally : does this also work if several CVI applications are running at the same time ? What do I have to do to get it working again ? In the documentation, I do not find nothing about this possibility.

 

Actually, I just want to be able to step into the execution - so, for example,  if I could place a "dummy" error in the source code that would force the IDE to popup at that position, this would be enough for me.

 

 

Many thanks in advance.

 


 

 

 

Message Edited by H-1 on 09-30-2009 07:25 AM
0 Kudos
Message 5 of 7
(4,116 Views)

actually, there is a registry setting which tells which debugger the system will launch when an application crashes. unfortunately, there is room for only one setting, and each time you install a development environment, it gets overwritten (visual studio, borland delphi, and even the kernel debuggers coming with the Windows DDK are using this setting).

 

the key is located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

i don't know what should its value be to debug with CVI... (and maybe it does not work at all with CVI). you can try repairing your CVI installation, it might reset those settings as it should.

 

(also, please consider creating a new thread to ask new questions: this thread is already solved so you may not get any answer when posting there)

Message Edited by dummy_decoy on 2009-09-30 03:33 PM
0 Kudos
Message 6 of 7
(4,103 Views)

Thanks for your quick reply; I meanwhile found the possibility to detect the use of uninitialized local variables at runtime (in the options dialog). When this happens, CVI pops up with a "break or continue" dialog, and with "break" I get to my "dummy variable" position from where I can step through the application further on. Maybe not all that elegant, but all that I need.

 

 

0 Kudos
Message 7 of 7
(4,100 Views)