CVIRTE.dll crash

[Sjoerdvandoorn]

Hello, We are experiencing problems with the CVIRTE.dll. We have a application using several hardware interfaces ( DAQ, DIO ) and software interfaces ( activeX (COMserver) ,DDE ). During operation of multiple applications on multiple XP machines, sometimes the CVIRTE.dll crashes.
Information
|CVI 6.0| CVI7.0
==================================================
Crash address: |0x001664DB|0x00195A8D
Crash module: |cvirte.dll|cvirte.dll
Module function | MinimizeAllWindows|MinimizeAllWindows
Function entry point: |0x0016503E|0x001944F7
Offset in function: | 0x149D |0x1596

We are not able to figure out why this crash occurs. National Instruments does not have a answer for us. does this problem look famili
ar to any of the readers, please let me know and better yet tell me what originates this problem.

Best regards,

Sjoerd

[bilalD]

Hello

Are there specific steps that you use to be able to reproduce this problem? The CVI RTE is supposed to be fully backwards compatible and should not cause unexpected crashes when switching between different OS�s. Since this crash seems to be occurring from the cvi RTE dll, it would be independent of the DAQ, COM and DDE interfaces.

You should be able to reproduce this problem by removing all the extra parts. This would help in narrowing down the problem and would help us in solving the problem faster. To be able to trace the problem, we need to be able to reproduce the problem in house. We have not had any reports of this problem occurring previously. I would recommend sending in an email to from ni.com\ask and sending in the application that is causing
the problem with the COM, DAQ and DDE (and any parts not essential to reproducing the bug) removed with steps commonly followed to effectively reproduce this crash.

Bilal Durrani
NI

[Sjoerdvandoorn]

I already sent the program to ni. But since the program crashes randomly, it is very hard to reproduce when stripping the software. I have not been able to strip the software in a way the problem still occurs. With the addresses listed for the two different DLL's (6 & 7) isn't it possible to look in the building listings and mappings to determine on what line of code the dll crashes ? This might give me (us) a clue on how to reproduce the problem and maybe fix/workaround the problem. This problem causes a lot of delay in the End of line testing of production.

Sjoerd

[bilalD]

Some sort of state information is becoming corrupted, which is why the program is crashing. And since this is occurring randomly, we will need that state information to determine why exactly this function would become unstable. Looking at just the line by itself will not tell us much. What I would recommend for you is to have trace statements or some error log track the execution path of your application. This way, where the application does crash, you will know which function was the last one to be executed. You can use the DebugPrint function to write messages to the debugger of your choice (windbg, CVI) and it won�t keep bringing the console window in front. Even the sequence of events (what panel was opened, which button was clicked, panel load
ed/discarded multiple times) would help a great deal.

Bilal