LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

GP fault

I'm getting the following error after running my app:
Fatal runtime error: unknown source position, thread id 0x0000018
The program has caused a "general protection" fault at 001B:100032DF.

This happens even when I comment out everything in main() and regardless of
which project I'm working with.
I'm using CVI 7.0 under Windows 2000.
0 Kudos
Message 1 of 6
(3,913 Views)
Hello,

This is quite a strange problem. Seems to me that something went wrong with you CVI installation. The first thing to try here is to "Repair" the CVI installation; go to Add/Remove programs, select "NI Software" look for CVI and launch the repair option. This should go through and check that all the files that CVI needs to run properly.

After this repair you can run some of the example projects ([CVI DIR]\samples. Make sure that you get those working correctly inside the IDE and running the EXEs outside of the CVI environment.

Please keep me posted.

Regards,
Juan Carlos
0 Kudos
Message 2 of 6
(3,913 Views)
I did as you suggested to no avail. After repairing my CVI install and
launching the treecopy sample by itself (not from CVI) I still got the same
GP on exiting the program.

Since I had ran my CVI apps with no problem only a few months ago, I
suspected that there must be a conflict with some other software that I had
installed recently. This turned out to be the case. I ran a system monitor
program called taskinfo (www.iarsn.com) and looked for any processes that
I didn't recognize and I noticed one called, "OCR Aware (32-bit)" launched
by
\Program Files\ScanSoft\OmniPagePro12.0\Opware12.exe.

So I terminated this process and ran treecopy again and this time it exited
with no GP! I repeated this test and looked at the modules loaded by
treecopy_dbg.exe before (with GP) and after terminating opware12 process
(no GP) and noticed that there was an ophook.dll loaded when the GP happened
but it was _not_ loaded when running treeinfo after terminating
opware12.exe.
This appears to be part of the OmniPagePro OCR scanner softwre that
I installed a few months ago.

I searched google for "ophook.dll" and found only one hit that mentioned
somebody else having an exception when running their Java app. This leaves
me wondering why having Omnipagepro's opware12.exe running in the
background causes both a CVI app and a Java app to GP fault and why
would the ophook.dll be loaded by them?

I can send you taskinfo's process snaphots if that helps. Even though
I know whats causing the problem, I'd like to know why its happening.
Thanks for any light you can shed on this.



"JuanCarlos" wrote in message
news:506500000005000000CD790100-1079395200000@exchange.ni.com...
> Hello,
>
> This is quite a strange problem. Seems to me that something went wrong
> with you CVI installation. The first thing to try here is to "Repair"
> the CVI installation; go to Add/Remove programs, select "NI Software"
> look for CVI and launch the repair option. This should go through and
> check that all the files that CVI needs to run properly.
>
> After this repair you can run some of the example projects ([CVI
> DIR]\samples. Make sure that you get those working correctly inside
> the IDE and running the EXEs outside of the CVI environment.
>
> Please keep me posted.
>
> Regards,
> Juan Carlos
0 Kudos
Message 3 of 6
(3,913 Views)
Hi,

Sorry for the delay... One thing to try here could be to create a console application with CVI that does not uses the Run-Time engine. I belive that the conflict with the second application will have to do with calling external dlls.

Another thing to try is to load the CVI Run-Time explicitly and unloaded at run-time; use the functions InitCVIRTE(...) and CloseCVIRTE(...).

I hope this helps finding more information on this.

Regards,

Juan Carlos
N.I.
0 Kudos
Message 4 of 6
(3,913 Views)
Per your suggestion, I created a console app (via CVI IDE's Target
Settings checkbox) and when I run it, the GP fault doesn't happen.
Then I added a call to InitCVIRTE() and CloseCVIRTE() in the same
console app and still no GP happens. You said a console app doesn't
_use_ the CVI RTE but even so, taskinfo shows me that cvirte.dll
is loaded by it. I also see that the ophook.dll is loaded as well.

Why would a console app which loads both cvirte and ophook dll's
_not_ cause a GP but GUI-based CVI apps which load those same dll's
run erratically and always cause a GP upon exiting?

There is something odd about the Opware12.exe's ophook.dll: its the
only dll based at an address that is a round number (i.e. 10000000).
Could this have anything
to do with causing the GP?

Maybe this additional info will help reveal the cause?

"JuanCarlos" wrote in message
news:506500000005000000827D0100-1079395200000@exchange.ni.com...

> Hi,
>
> Sorry for the delay... One thing to try here could be to create a
> console application with CVI that does not uses the Run-Time engine. I
> belive that the conflict with the second application will have to do
> with calling external dlls.
>
> Another thing to try is to load the CVI Run-Time explicitly and
> unloaded at run-time; use the functions InitCVIRTE(...) and
> CloseCVIRTE(...).
>
> I hope this helps finding more information on this.
>
> Regards,
>
> Juan Carlos
> N.I.
0 Kudos
Message 5 of 6
(3,913 Views)
Hi,

To create a console aplication that does not loads the cvirte.dll you need to go to the target settings and select "Instrument Driver Only" under Run-Time support. However seems that there is not a problem loading dlls.

Given the name of the conflicting dll this could be a system hook created to monitor som specific message or event; and this is where it could conflict with CVI. It's virtually impossible to know what or where the dll is conflicting.

You could be able to nail down the problem by starting with a sinple panel that catches no events then start adding features until you get the GPF; You can also construct and destroy your UI programatically, this way we can get the specific operation that is causing the f
ault.

Unfortunatelly there is no easy solution for this; I would recomend to try to talk to the companie that makes the scaner software for any known issues or updates.

Regards,

Juan Carlos
0 Kudos
Message 6 of 6
(3,913 Views)