Crash of cvirte.dll 8.5.1.356

[Rolboes]

Hello,

I have a strange error on ring controls. I have 5 ring controls where the users selects predefined values. I exprerience intermittent application crashes with the following error:

Faulting application carchiptw.exe, version 0.2.0.0, faulting module cvirte.dll, version 8.5.1.356, fault address 0x002362d1.

It only happens from time to time, when the user selects a value from the ring, and only in the released application. The debuggable executable (_dbg.exe) does NOT crash.

It did not happen with CVI 8.0 but only since 8.5 and 8.5.1.

Regards

Roland

[CorbinH]

Hi Rolboes,

I have a few questions for you. Does the released executable work on any other machines or does this problem only occur on one computer? Also, could you tell me a little bit more about the application? Has anything changed in your code since upgrading from 8.0 to 8.5.1?

[Rolboes]

Hi,

The code runs fine on my development PC, but not on the production PC. So I decided to install CVI on the production PC as well and compile the code there, as the PCs use different processors. It did not change the behaviour at all. The application crashes at random intervals, when the uses selects a value from a ring control. But it may run without any problem for 3 days. The ring controls are included in the UIR file with data type 'string (*char)'. At compile time each ring control contains one item. When the application starts, the additional values are retrieved from an Oracle table using the SQL toolkit and inserted into the ring with : InsertListItem (panelHandle, ctrlID, 1, display_buffer, column->data.text). 

I use this method in many other programs, without any problem.

Regards

Roland

[CorbinH]

Rolboes,

One thing you might try is commenting out the part of your code that retrieves the list from Oracle and instead manually adding the lists in your code. This will help determine if the problem is occuring when you try to access Oracle or if it is something else within the code. Another possibility is a race condition that is occuring. Since the debuggable version works just fine (and debuggable versions don't execute as fast) then that is a possibility. My first recommendation is to check how your code is receiving information from Oracle.