CVI Fatal Error

[sebastian_z]

Hi all,

I have to solve a problem with a fatal error in CVI. I'm totally new in this project but do have much experience and knowledge in C and lowlevel programming as well as Hardware programming (VHDL).

That said I start describing the problem: the CVI program sometimes crashes with a fatal error and a hint to a memory address problem. The least significant bytes of the address are always 0x7712 regardless of the computer the program is running. Unfortunately there is no further information provided and we cannot investigate which function is the root cause for the crash.

In Linux I would use the strace tool for debugging. Is there a similar tool provided by NI because the error message is not meaningful at all and we have no chance to find the error.

Kind regards

Sebastian

[RobertoBozzolo]

You could for example recompile the program with  "generate map file" option enabled and compare the address with those found in the generated file: hopefully you can find the function where the error arises. 

That option can be found in Build >> target settings 

[sebastian_z]

Hi Roberto,

grazie mille! Now I'm waiting for the error because none of my colleagues has memorized or written down the exact memory location of the error (0x7712 was just an example). So exceptionally I hope the error occurs within the next few hours. 🙂

Kind regards

Sebastian

[RobertoBozzolo]

I see. Do I have to wish you that it runs or fails? I'm not sure 

Mysteries of debugging 

[sebastian_z]

So at the end I had luck and at the same time no luck (greetings from Schrödinger's cat  ).

The error occured two times within one minute at a colleague's computer. He made a screenshot of both error messages. Here they are:

And here the second screenshot:

Unfortunately this address is not in the map file. Not even the beginning of it, I tried it out without the 7712 at the end because I tought it could be in the middle of a called function. But not even the 7FEFF (most significant bytes of the address) is found in the map file. I hope someone can give me a hint. 🙂

Kind regards

Sebastian

[RobertoBozzolo]

This is kind of a problem: such a high memory address implies the faulting module is not your actual program, unless you have explicitly set the base memory address in build opitions to a near value. I assume you don't since you cannot find the address in the map file.

There are several threads in the forum that address those "non debuggable thread" errors, e.g. this one; there are other discussions but most of them are strictly related to a particular configuration or library used and may not apply to your scenario.

Generating a crash dump can be useful if you can understand what's in it or at least the faulty module name. Try also looking the event viewer in case the OS has dumped some info there.

Which OS are you running on? Is your app 32- or 64-bit? Can you at least reduce the cause of errors to a particular activity or function in the program?

[sebastian_z]

Hi Roberto,

thanks for your great help. I and my colleagures, we are all running the same OS: Windows 7 64-bit. Unfortunately the answer to your question is no, we cannot reduce the error to a particular function. I thought about the FTDI library. We are using the FTDI chip to transfer data from our FPGA to the CVI program. This library is provided by FTDI. But I don't think that there is an error because hundreds or thousands of people use these chips and this library.

Kind regards

Sebastian

[sebastian_z]

A colleague of mine has made an interesting discovery: He noticed that the software does not crash if he does not run it out of the debugger. I don't know why all my colleagues start the exe from the debugger but so far they do so, no matter if the are working at the software itself or just use it.

So is it possible to assume a relationship between starting the exe from the debugger and starting the exe directly?

Kind regards

Sebastian

[RobertoBozzolo]

Yes, I know things are complicated here!

What you can do is to examine the system with some utility and get a process dump when it crashes. Microsoft offers some SysInternals utilities (see here) that could help you like Process Explorer, Process Dump, Process monitor and other that can add information as to what's happening at some moment. I hope you can get some info on your problems from that.

[RobertoBozzolo]

---

sebastian_z ha scritto:

A colleague of mine has made an interesting discovery: He noticed that the software does not crash if he does not run it out of the debugger. I don't know why all my colleagues start the exe from the debugger but so far they do so, no matter if the are working at the software itself or just use it.

So is it possible to assume a relationship between starting the exe from the debugger and starting the exe directly?

Kind regards

Sebastian

---

Sorry I dodn't read your reply before writing. What do you mean by "starting from the debugger"?