Foxpro7 crashing with "fatal error exception code=c0000005 ..."

Hi
I have a tricky issue in my VFP7 application. At least tricky for me. 

The application is crashing with fatal error C0000005. Sometimes I see a message like this one in the eventlog: "Faulting application <appname>.exe, version 1.4.82.0, faulting module ntdll.dll, version 5.1.2600.2180, fault address 0x00010f29.". Sometimes the application just hangs. I also see the Windows error "The instruction at "0x...." referenced memory at "0x.....". The memory could not be "read"", and then the application is closed, of cource.

The error does only appear in situations where I print, but it does not occur in an exact pattern, or when I pass a particular code line. I use a third party dll called foxpp.dll (fox power printer) to get my "hands" on the windows printernames and properties. (I don't think the supplier exists anymore ). Since the crash does not occur when i run a particular line of code, and even sometimes when i close a window, it is hard to tell the exact reason. I am suspecting the printer dll, but it might also be other reasons. Does anyone know of a tool (or a method) to find the point where the illegal memory access occurs

The error seems to appear more often after a couple of consecutive prints. So I am thinking that a "reset" of the print objects (the loaded dll) might be a way to reduce the problem, if not removing it. Any hints how to do this "reset" in a good way

Helpful hints are highly appreciated on this "blurred" question :-)

Best regards, Endre

Hi!

SP1 is installed, and FoxUser files are deleted from the location where " sys(2005)" tells me they are located (and from the other locations where I find them, also)

I have the problem with both HP printers and a Minolta printer. I use an OCX to print an Activereports report, and I think it might be this OCX that can be the issue. The application often crashes after a couple of prints. Seldom or never on the first one. I just cannot find the right way to "release" the objects in the right way, obviosly. Or maybe it is not the OCX, just the VFP use of printers.

Best Regards Endre

How can I check if a dll "remains hanged" in memory

- - -

Endre

Hi!

Thank you for your kind answers. I was/am (nearly) going mad over this one :-S. I thought for a while I have a working system again. On my PC it works fine now, but the client tester still see the same problem. I don't know _why_ it works at my PC, but I know what made it work:

I have managed to isolate the problem further:

The error appeares when applying an ocx for print: ActivereportsViewer, arview2.ocx. This ocx is added as a control to a VFP form. The ocx receives an active reports report from a .Net web service as data source and prints it. Around the third print, I see the fatal error (c00..5) - sometime just a hanging application

I tried to release all objects and setting them to .NULL., but no improvement. Then I created the same ActiveX as an object in the form (CREATEOBJECT("DDActiveReportsViewer2.ARViewer2.1")), and set the same datasource for this one. Then I tried to print from this one instead, no print produced, BUT the print from the ActiveX-control in my form works, and I don't see the c0000005 no more!! My theory is that when I create the same object with "CreateObject" and afterwards sets it to .NULL. VFP manage to release it properly. But obviously not perfectly since another PC has the same issue still.

I am still kind of confused regarding what's going on. Further inputs are welcome :-)

Best regards

Hi!

It seems that the described actions are successful after all. We have now positive tests on the client PC's and on Citrix hosting the application.

Endre :-)