LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Error: "Unrecoverable Internal Error at 001B:100D304C. LabWindows/CVI will be aborted"

I use LabWindows/CVI 7.0 and following error message "Unrecoverable Internal Error at 001B:100D304C. LabWindows/CVI will be aborted" comes often while compiling+building my application.

If you have any suggestion how this could be avoided, please answer.

Is this kind of problem eliminated in version 7.1?
0 Kudos
Message 1 of 14
(5,084 Views)
Could you give some more information? What does your project use? Does this happen all the time consistently? Does this happen at runtime? You can download the eval version of CVI 7.1 and try compiling it with that to see if this still occurs.


Hope this helps
Bilal Durrani
NI
0 Kudos
Message 2 of 14
(5,072 Views)
It comes when I want to compile/build my application or run it. So never at runtime.
Actually I work in debug mode, I don't know if it happens in release mode.
It does not come systematically, so I can work on my application and start it.

It can also come if I open my *.cws file and then start the allready compiled debug project with the Run button. Doing that same thing gives me also sometimes "An error occured while loading debuging information for 'MyProject_dbg.exe'. You will be unable to debug this DLL/EXE. If this DLL/EXE was built with an earlier version of LabWindows/CVI you might have to rebuild it using this version. Would you like to terminate execution?"
I don't really know if it has the same cause or not.

The project I am working on was started with an earlier version of LabWindows/CVI, I have worked on it with LabWindows/CVI 5.1.1 and yet I use version 7.0 since August 2004. But sure, I have rebuild it many times since there.

I am using some instrument driver (.fp) from NI in my project, and also some dlls.
0 Kudos
Message 3 of 14
(5,065 Views)
I think I have solved the problem, if it can help other people:

While opening my *.cws file, CVI was always recompiling some *.c files, as toolbox.c, corresponding to the *.fp files.

So I have dettached all the *.c files that were linked to the *.fp files I am using and replaced them with the corresponding *.obj file, to avoid recompilation of those *.c files.
(Remark, take care because CVI reattaches automatically the *.c files if they are in the same folder as the corresponding *.fp file).

I was also using tooltip.fp but had not the tooltip.obj. So I searched on the NI site and found that yet tooltips are directly available from the toolbox.fp, so I used the function from the toolbox instead and removed this other *.fp

It seems yet to work fine.
0 Kudos
Message 4 of 14
(5,061 Views)
Hi,

i too also had this error before and do not really know why

"An error occured while loading debuging information for 'MyProject_dbg.exe'. You will be unable to debug this DLL/EXE. If this DLL/EXE was built with an earlier version of LabWindows/CVI you might have to rebuild it using this version. Would you like to terminate execution?"

even after rebuilding using the new version i too had the same problem. In the end i just created a new project and reattached the source files.

Cheers AL
0 Kudos
Message 5 of 14
(4,953 Views)
Hi Rac,

i too am using instruments in my project and i'm wondering if i can reduce the amount of files needed or something. I'm new to using the instruments and am not really clear on how it really works. Previously, i only copied the *.fp to my project folder and included it into project but upon compiling, i have lots of errors. Then i copied all the files, i think which links to the *.fp. Are all these files really necessary? Please see below:

- asynctmr.c, asynctmr.fp, asynctmr.h, asynctmr.obj
- Easytab.c, Easytab.fp, Easytab.fpc, Easytab.h, easytab_cct.c
- msie.c, msie.fp, msie.h, msie.sub
- RICHTX32.c, Richtx32.fp, Richtx32.h, Richtx32.obj, Richtx32.sub
- toolbar.c, toolbar.fp, toolbar.fpc, toolbar.h, toolbar.obj

Is there something which i can change or something??

Cheers
AL
0 Kudos
Message 6 of 14
(4,950 Views)
Hi AL,

Add the *.fp files to your project (they don't necessary have to be in the project directory as you thought). What you need to have in the same folder as your *.fp file is either the *.c file either the *.obj file.

If you use the *.obj file you will avoid that CVI recompiles the c file, so you will avoid some borrying warnings coming from this c files and also avoid from the "An error occured while loading debuging information for 'MyProject_dbg.exe'. You will be unable to debug this DLL/EXE. If this DLL/EXE was built with an earlier version of LabWindows/CVI you might have to rebuild it using this version. Would you like to terminate execution?" error as some Unrecoverable Internal Errors.

Take care that if the c file is in the fp folder it will automatically be attached to it from CVI.

And of course you need the related header file *.h.

Rac
0 Kudos
Message 7 of 14
(4,941 Views)
If you can post a project here that replicates the problem, that would help us track down the problem. Or if you cannot post the project here, let me know and I can contact you offline.

Thanks
Bilal Durrani
NI
0 Kudos
Message 8 of 14
(4,924 Views)
Hi Rac,

so it means that either i have the *.c or *.obj together with the *.fp. And *.h is a must. What about *.fpc and *.sub? Do i need them?

Actually what does all these *.sub, *.obj, ..etc do?

Are all these actually provided somewhere in NI? i got all these instrument files out from the samples of certain projects.

Will they still be able to function if i migrate to different versions later on in future?

For example, we include or in our projects, but we do not exactly need to copy these header files into our project. It is automatically link to the folder where we installed the program.

cheers
AL

Message Edited by AL on 04-12-2005 09:01 PM

0 Kudos
Message 9 of 14
(4,921 Views)
Hi bilaID,

I'm sorry but i am unable to recreate the error. It happen when the project was created in CVI 6 and i had to use CVI 7. I do not have the old project anymore.

cheers
AL
0 Kudos
Message 10 of 14
(4,916 Views)