LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Save runtime error information into the log file

Sometime I am using debug build on the production tool - I inherited a few legacy projects with not a great design, so I would like to to catch "out-of-boundary" or "null reference" fatal errors. Crash (termination) of the software in this case is acceptable for us - it is better than running in unknown state or crash with Windows access violation (GPF) error message.

 

The benefits - error message has file name and line of the code where run-time error occurred. There is a main problem appears: information displayed in the popup window only which requires somebody to be present at the system to press "Break" button. Also, as soon as button pressed error information will disappear. So, making a screen shot is required to document issue.

 

Is there any way to intercept standard error message box so I can write error information into the log file for the future analysis and terminate program?

 

I searched around and I know about:

  1. SetBreakOn... functions - this will not help

  2. chkErr/chkNull and similar macro will not work either - I do not have resources to go through all projects and add this macro in every line of code

  3. My program is just an executable, so I can't use ActiveX ERRORINFO features.

 

Debug build with cdb file provides all I need, except usability. I am surprised in XXI century there is no way to dump error information in the log.

0 Kudos
Message 1 of 9
(5,098 Views)

Hello jorsh,

 

Consider using the ConfigCVILogging.exe at National Instruments\CVI2012\bin to configure data logging. One of the options is to save the errors to a file which you might need. Hope this helps!

Ian M.
National Instruments
0 Kudos
Message 2 of 9
(5,079 Views)

Thank you for quick response.

 

Either I am doing something wrong or this recipe is not what I am looking for:

  1. ConfigCVILogging.exe is not a part of runtime engine. It is part of CVI Development. So, I copied this executable on the Lab machine and configured runtime logging.

  2. To test I created very simple project that generates "Null pointer argument" Fatal error with source information when running debug build with in the presence of CDB file (please see attached CVI-Fatal-error.jpg and executable compiled with CVI 2012)

  3. Than I run this executable on the machine with runtime configured to log errors in the file (C:\CVIDebugLog.txt) and it is nothing there reference the error:

=====

[14:08:43.028] [ERROR] [WMain] [..\jsource\lvcompat.c:3846] Failed to initialize low level driver for NT.
[14:08:45.275] [WARNING] [TcpIpRestartClient] [..\jeff\debugger\tcpipdebugapi.c:676] Err = -12600
[14:08:45.275] [WARNING] [CVIDebugStopTcpIpDebugging] [..\jeff\debugger\cvidebugtcpip.c:3220] Err = -12600
=====

 

So, please let me repeat my question: is there any way I can set callback, or intercept PopupMessage call, or have some magic macro that will allow me save file and line information that will be anyway shown on the screen?

Download All
0 Kudos
Message 3 of 9
(5,073 Views)

So if my understanding is correct you want a way to programmatically recognize when a message window popup has occurred to capture the error information on that pop up? There are ways to programmatically have a function take a screen shot and save it to a file but I'm not sure there is a way to recognize when an executable has a message window appear in order to call that function to save the screen shot.

Ian M.
National Instruments
0 Kudos
Message 4 of 9
(5,052 Views)

You got the idea. I do not need a screen shot, just information from the pop-up window. I believe somewhere in the CVI there is a global function active only in debug build that doing something like this:

 

if(error) {

   PopupMessage(error, filename, line);

   exit();

}

 

What I am looking for is the way of doing something like this:

 

if(error) {

   PopupMessage(error, filename, line);

   if( userfunc!=NULL )

        userfunc( error, filename, line );

   exit();

}

 

Where userfunc() will be user definable call back function that will perform whatever I will put there. This will be very usefull because will not require chaning existing code - in contrary with the chkNull or assert macros approach.

 

I worked with different languges (mainly MS C/C++/C#, PHP) - all of them have some sort of a "hook" when you can set callback function that will be called in case of something like "unhandled exception" (in terms of C++/C#) will happen. This function usually has access to the error information, so I can record it. The great things is that if I have binary file (EXE or DLL) compiled with debug information available (same is for CVI) it can point right into the line of source code where the error happened.

 

Screen shot will not work well here:

1. It is hard to require operators be able do something like this. Sometimes it is also imposible to wait until somebody available who can make it.

2. Automation does not work either, because how I would know when the pop-up appears?

 

I was thinkng of the way to subclass window function (using Win32 API) for the error message box or something like this, but stiil not found the right way to do it.

0 Kudos
Message 5 of 9
(5,041 Views)

I would think that you should be able to see in the Windows' Application Event Log any errors that caused your application to crash.  It should give an Exception Code that tells you what kind of error it was (look in WINNT.H for the list of exception codes) and an offset that you should be able to look up in the map file (turn on the creation of the map file in the Target Settings in CVI) that will tell you approximately where the crash occured.

0 Kudos
Message 6 of 9
(5,039 Views)

Thanks tstanley.

 

This works only for release build. When application compiled as debug build CVI asserts a certain errors (NULL pointers, array out-of-boundary) and this does not go as the normal GPF failure. I prefer CVI way of error checks against just a waiting for GPF because it helps catch issues that may not necessarily cause GPF. For example, array out-of-boundary error may or may not cause GPF - it depends on current memory allocation map. However, when writing to array it may corrupt internal data and unnoticeable lead to compromised results.

 

In my particular case I have to support a few (that is close to many) legacy projects with pretty poor code quality sometime revealing wired behavior - so I want to be sure that type of errors is not the issue. I am not concern about the overhead all these extra checks will create - my processes are quite slow.

0 Kudos
Message 7 of 9
(5,033 Views)

I guess another thought I have, which probably won't work for what you want, but I'll throw it out there anyway is the remote debugger:

http://www.ni.com/white-paper/3384/en

 

That would throw any errors to your development machine showing exactly what happened.  Disadvantages though would include tying up a development machine whenever the application is running, the application appearing to hang up and freeze instead of shutting down on the target machine when something happens (until you stop the application in the debugger), the fact that both PCs would have to have a network connection, and possible performance issues.

Message 8 of 9
(5,028 Views)

Unfortunately 🙂 you are right - this does not help either. As I said I have a few projects (~10) that are running on a few (~30) computers... Event though we have reasonable network and I am not too concerned about speed I do not see how to setup this. Also, most of the time this happened in the middle of the night when nobody is around.

 

This is enother thing - in MS C++/C# I have ability gracefully shutdown system in this case (just turning OFF all the equipment) before the software exits.

0 Kudos
Message 9 of 9
(5,023 Views)