error cvirte 7.1

[RobertoBozzolo]

Hi all,

we are facing a strange behaviour in an application that has been running for months without problems and has begun in the past days to raise a windows error. The customer reportedsimply that standard windows error dialogue appeared and application crashed while it was performing a test.

After diggin in the Events log I have found several items marked "Application error" followed by another marked "DrWatson".

The "Application error" details are the following:

Application failure S450_11.exe 1.0.0.0 in cvirte.dll at offset 0011d888

Origin: Application error

Category: none

Event ID: 1000

The subsequent DrWatson event recitates:

Exception c0000005 at offset 6853d888 (cvirte!UP_StringUpperCase)

Origin: DrWatson

Category: none

Event ID: 4097

Now, exception c0000005 means "access violation" but I am not using StringUpperCase command in that application 

The system is running WinXP Pro SP2, installed CVI RTE is 7.1.1.313

What can this error mean? Could updating the RTE solve this?

Can I perform some additional tests to better locate error origin?

[LuisG]

Hey Roberto,

If you're able to reproduce the problem reliably, and are also able to debug the program, my first suggestion would be to step through the code until you can narrow down where exactly this is coming from. And if you include open-source instruments in this project, step through those as well.

Unfortunately, I don't have a map file for the 7.1 run-time engine so I can't look up that address. And I don't trust Dr. Watson's match of that address to UP_StringUpperCase, since Dr. Watson is probably just looking through the list of exported functions and finding the one that has the closest base address to 6853d888. The access violation might not be in that function at all.

However, if downloading and installing the latest version of the CVI runtime is a possibility, that would certainly help. For one, it might make the problem go away altogether (this might be an old CVI bug, who knows...). But even if the problem doesn't go away, we can then get a much better idea of where the access violation really is.

Luis

[Wolfgang]

Hi Roberto,

your mention of the proper long time behavior reminds me of the problem encountered in earlier versions of CVI with the timer function, which works fine for something like 49 days but then, after 2^32 counts, results in 'difficulties'. Could this be a reason in yor case? 

[RobertoBozzolo]

@Wolfgang: Thanks for your suggestion: I am aware of the problem with timer rollover and took some countermeasures for it, but in this case the program is not running so much time continuously.

@Luis: the problem is that the error is not reproducible: last week the program couldn't run for more than an hour whitout errors  ; today I put myself on guard in my customer's laboratory but the bench worked regularly for the whole day 

Moreover, in bench PC only the runtime is installed, not the complete IDE...

I will try to install a newer RTE and see if this has beneficial effects.

Message Edited by Roberto Bozzolo on 05-26-2010 11:30 PM

[menchar]

Roberto-

That exception occurs when you get a data execution exception.

Try turning off the data execution prevention service and see if the problem goes away.  Someone may have turned it on, or OS may have been updated.  You get to it through the control panel -> system -> advanced -> performance settings ->  dep

It could be there's a latent flaw in the app with an occasional buffer overflow that went undetected with earlier OS but now when it happens it causes the DEP to fault.

I have seen this on functions that manipulate strings - once in a while you get a string longer than expected, you're running release mode so no dynamic bounds checking, and then buffer overflow and a DEP exception.

Menchar

Message Edited by menchar on 06-01-2010 06:35 PM

[judyh]

Hi Menchar,

I am seeing a similar situation with one customer to whom we recently sent an update built using CVI 9.0.  I will ask them to also try this solution to see if it works.  We use cvirte version 9.0.1.375, so I don't know if upgrading will help Roberto.  Hopefully, this takes care of it.

Thanks for the info.

Judy Harrigan

[menchar]

Judy -

Every instance I've ever seen of that exception, c0000005, has been from DEP firing on a WinXP system or later after a buffer overflow or bad pointer dereference.  I imagine there might be other causes, but I haven't seen any others.  I think the exception means the overflow is in the 'user" portion of the process's address space, when I've overflowed a system buffer the results were more catastrophic - instant crash with no popup or exception of any kind.

You can try deploying a debug build, you can run a debug build stand-alone , without the IDE, and you get the bounds checking that results in a source-referent popup when a buffer overflow occurs.  You might have to set "extended" on the debug level to get all the run-time checks into the debug build.  Debug builds are larger and slower than a release mode build.

You can use aggressive compiler warnings too for more insight as to possible problems.  You can try compiling with another compiler, say the Intel or VCPP compilers, they can generate far more extensive warning info than the native CVI compiler.  I've used the Intel compiler for this, it always amazes me how many legitimate flaws it can find in CVI code that was warning and error free with the native compiler.  Or try a static analyzer.

Menchar

[judyh]

Menchar,

Thanks again.  I'll have the customer try fixing the DEP.  I also noticed (this is legacy code - don't blame me!) that the code uses VirtualAlloc to allocate space for incoming data from one of our products.  It is when data is incoming that the error is being generated.  I'm wondering if it is related to the use of the VirtualAlloc function.  This is a Windows function that allocates virtual pages of memory.  This may be the memory area you're talking about.  It is actually unnecessary for the code to make the call - a simple static allocation of array space for the data will do just fine - but when the code was first written, they were probably facing memory issues.

Judy

[RobertoBozzolo]

Just as a follow-up, simply installing the 8.5 runtime fixed the error. I had no more occurrences of this problem. There are other kind of errore in the equipment but are related to some external device not operating properly: I don't think they are related to the RTE installed.

[menchar]

Roberto -

Perhaps it was a buffer overrun issue with that particular function in the older RTE version that was usually benign but when DEP is active shows up as an exception, whether or not the actual effect is fatal to the application.

We had seen that same sort of problem as well, old code that ran fine on Win2K then we installed on WinXP with DEP enabled and all of a sudden exceptions were getting thrown.

I wonder if CVI 7.1 predated WinXP and NI spotted this problem when XP was released and they fixed it in 8.x RTE.

Menchar