LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

EXECUTABLE CRASHES

Hello

We ask for help with a crash problem with our application developed in LW CVI 2019.

 

We attach below the crash report, as taken from "Event Viewer

- Windows Registry - Application"

 

As you can see, it appears to be an error related to cvirte.dll.

 

The installed application closes brutally, without the usual Windows error message, both in RELEASE and in DEBUG, which makes us think that it is indeed a cvirte.dll problem. Obviously these are suppositions.

 

The innovations implemented in the application (which in general has been running without problems for years) are: a TCP Server to connect to another process on the same PC and the fact that the executable never shows its own screens, but only when requested by the client TCP.

 

Can you help us understand the problem?

 

Thanks a lot

 

Log Name:      Application

Source:        Application Error

Date:          06/03/2024 00:09:16

Event ID:      1000

Task Category: (100)

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      Pressa2169

Description:

Faulting application name: MYAPP.exe, version: 3.0.0.612, time stamp: 0x65e74714

Faulting module name: cvirte.dll, version: 19.0.0.49154, time stamp: 0x5c94e67e

Exception code: 0xc0000005

Fault offset: 0x0018a560

Faulting process id: 0x1208

Faulting application start time: 0x01da6f1c1717e235

Faulting application path: C:\...MYAPP.exe

Faulting module path: C:\windows\SYSTEM32\cvirte.dll

Report Id: 424bb894-cdeb-4f17-9a04-0e796ad0de86

Faulting package full name:

Faulting package-relative application ID:

Event Xml:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

  <System>

    <Provider Name="Application Error" />

    <EventID Qualifiers="0">1000</EventID>

    <Version>0</Version>

    <Level>2</Level>

    <Task>100</Task>

    <Opcode>0</Opcode>

    <Keywords>0x80000000000000</Keywords>

    <TimeCreated SystemTime="2024-03-05T23:09:16.3172916Z" />

    <EventRecordID>10619</EventRecordID>

    <Correlation />

    <Execution ProcessID="0" ThreadID="0" />

    <Channel>Application</Channel>

    <Computer>Pressa2169</Computer>

    <Security />

  </System>

  <EventData>

    <Data>MYAPP.exe</Data>

    <Data>3.0.0.612</Data>

    <Data>65e74714</Data>

    <Data>cvirte.dll</Data>

    <Data>19.0.0.49154</Data>

    <Data>5c94e67e</Data>

    <Data>c0000005</Data>

    <Data>0018a560</Data>

    <Data>1208</Data>

    <Data>01da6f1c1717e235</Data>

    <Data>C:\...MYAPP.exe</Data>

    <Data>C:\windows\SYSTEM32\cvirte.dll</Data>

    <Data>424bb894-cdeb-4f17-9a04-0e796ad0de86</Data>

    <Data>

    </Data>

    <Data>

    </Data>

  </EventData>

</Event>

0 Kudos
Message 1 of 4
(351 Views)

Before all, you mention that the application crashes in debug as well: do you mean running an executable created in debug mode or running while inside the IDE?

 

I tend to consider strange a bug inside the RTE: while it's not impossible, the RTE is a robust module, tested over several scenarios and not likely to be faulty. In my experience problems normally arise in some call your code does to RTE functions, which for some reason is incorrect and produces unexpected results (incorrect parameters type, pointing to wrong memory areas or so).

 

The usual way to address this type of problems is to generate the map file while creating the executable and then cross-match the address you find in event details with the map file to at least locate the function where the error arises.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 2 of 4
(311 Views)

Hello

Thank you for your answer

We are now carrying out "inside the IDE" tests, but the crash occurs sometimes after hours, sometimes after days (and it seems to us that, in the conditions of use, the operations executed are always the same cyclically). With the "Inside the IDE" tests in your opinion do you think we have hope that IDE will show us the crash point?

In the map file (generated afterwards by recompiling the executable in the IDE) I read:

01000000 Base address

So since the fault is in 0x18a560, adding base address I find:

0118A560 Fault address

Reading in map file:

011895B0 001889B0 EXTERN _ScriviREGOPLAS pagAccessori.obj

0118B320 0018A720 EXTERN _PlcAggiornaREGOPLAS pagAccessori.obj

0118BF70 0018B370 EXTERN _IniezUpdateREGOPLAS pagAccessori.obj

which are certainly functions not executed at that time.

Waiting for some suggestions, again thanks a lot!

 

0 Kudos
Message 3 of 4
(302 Views)

As somebody who has found actual bugs in the CVI RTE in the past I can also attest that these are pretty rare, the working assumption should be that the problem is in your code.

 

If the crash is in user code, the CVI IDE can sometimes point to it if you're lucky. If not the IDE debugger is useless. I use WinDbg in these cases (free from Microsoft) but even with the new version with better user interface it might not be exactly easy to use. Best case let it run under WinDbg, it will stop at the crash and when you look at the raw stack ("kL" command) and cross-reference the addresses with the MAP file you get an idea what's going on. If not, specialized knowledge is needed that cannot be taught over a forum post, sorry.

0 Kudos
Message 4 of 4
(200 Views)