how to get rid of the internal error message?

[i2dx]

Hi folks,

since working with a FPGA in my latest project I get an internal error message EACH time, I start LV. Ok, that does not really bother me, because anything is working fine, but can it be, that LV really *crashes* each time, I close the SW?

http://forums.lavag.org/index.php?act=attach&type=post&id=5621

BTW: do not tell me to set the checkbox to ignore internal errors

[Grampa_of_Oliva_n_Eden]

QUOTE(i2dx @ Apr 24 2007, 03:17 PM)

...but can it be, that LV really *crashes* each time, I close the SW?

http://forums.lavag.org/index.php?act=attach&type=post&id=5621''>http://forums.lavag.org/index.php?act=attach&type=post&id=5621'>http://forums.lavag.org/index.php?act=attach&type=post&id=5621

...

Check "C:\Documents and Settings\bar\My Documents\LabVIEW Data\lvfailurelog".

A new files is written there for each crash.

Ben

[Ton Plomp]

Repair LabVIEW?

Ton

[Tomi Maila]

I've been gettin similar error messages daily in LV 8.20 and sometimes even with LV 8.2.1. As LabVIEW still works flawlessly, I've not really paid much attension. Reinstalling LabVIEW doesn't help. I've never used FPGA so it cannot be the only reason for these messages.

Tomi

[Darren]

There are a couple of internal errors in LabVIEW called "DWarns" and "DAborts". You'll get that dialog on launch if a DWarn or a DAbort occurred on the previous run of LabVIEW. A DAbort is a crash, but a DWarn could be some internal error that LabVIEW logged, but LabVIEW was still able to continue operating normally. If you click the "Investigate Internal Error Now" option, you'll be taken to a webpage that will perform a search of the NI Support site to see if that internal error has any KnowledgeBase entries associated with it. Assuming your error does not, you can submit your log file to NI Tech Support, who sends all of these error reports on to LabVIEW R&D. If you can reproduce the DWarn/DAbort with some simple steps, it would also be helpful to submit a sample VI (if applicable) along with the error log.

Hope this clears up the issue, let me know if you still have any questions.

-D

[i2dx]

QUOTE(Darren @ Apr 25 2007, 01:00 AM)

If you click the "Investigate Internal Error Now" option, you'll be taken to a webpage that will perform a search of the NI Support site to see if that internal error has any KnowledgeBase entries associated with it. Assuming your error does not, you can submit your log file to NI Tech Support, who sends all of these error reports on to LabVIEW R&D. [...]

Hope this clears up the issue, let me know if you still have any questions.

Daren, it’s good, you answered, I wanted to address one of the NI guys here. It seems, that I always get these errors, which are not in the CAR , because I never found any helpful information about the *crash* on the webpage. It does not really bother me, because LV is working fine, and if not, I'd torture (again) an AE with my issue, until I can continue my work

Anyway, maybe the Suggestion Page would be a better place for this, but I'm unsure, so, I'd like to ask the question here, if NI could make this part of LV a little bit more convenient and I have a suggestion:

The way MS handles crash feedback is almost optimal. They do not bother you with many questions, they just ask you in the first step, if you want to send the crash report or not. If you want to, you can get detailed information and more detailed information, if you want to, and if you are interested in the details of the file, which is sent to MS. I'd be glad, if NI would handle crash reports the same way. You (NI) can decide on your side, whether this crash reports matters or not, and if you think it does not matter, then you can increment the counter on crash xzy and delete the file. You get the statistics and the user gets the good feeling that someone is caring about his issue. Using the webpage for the search for further information about the crash leaves a bad feeling, if there is no answer and you are left alone with the decision, to send an email to R&D or not. So I would only show a button "find information for that issue on our webpage", if there ARE information on the webpage.

What do others think about that?

[Rolf Kalbermatter]

QUOTE(Darren @ Apr 24 2007, 06:00 PM)

There are a couple of internal errors in LabVIEW called "DWarns" and "DAborts". You'll get that dialog on launch if a DWarn or a DAbort occurred on the previous run of LabVIEW. A DAbort is a crash, but a DWarn could be some internal error that LabVIEW logged, but LabVIEW was still able to continue operating normally. If you click the "Investigate Internal Error Now" option, you'll be taken to a webpage that will perform a search of the NI Support site to see if that internal error has any KnowledgeBase entries associated with it. Assuming your error does not, you can submit your log file to NI Tech Support, who sends all of these error reports on to LabVIEW R&D. If you can reproduce the DWarn/DAbort with some simple steps, it would also be helpful to submit a sample VI (if applicable) along with the error log.

Hope this clears up the issue, let me know if you still have any questions.

-D

In that respect just something that came up on Info-LabVIEW again. It would be useful to add to the error translation routine that handles file IO an explicit DWarn call when a "generic IO Error" gets generated. Not sure if DWarn can do that now but a complete stack trace with it would be fine too.

This would allow the LabVIEW R&D guys to possibly get a better feeling, which strange or obscure Windows API error resulted in a generic IO error. They are not likely to be very common errors, (or they would have been translated in a more useful error code) and the according log would give some better hints to the developers where to look for the cause of this error.

Of course there are other errors (for example network routines) that can end up in some sort of catch all unexpected errors into a single generic XXXX error.

Rolf Kalbermatter