program crashes with Fatal error:Exception code=C000006

[lclock]

Hi, we are delivering our application to a larg firm.
Application is compiled with VP6 sp.2
Is installed on Windows Server 2008 R2 with terminal services enabled.
It happens some random crashes with Fatal error:Exception code=C000006.
We've never had this problem on other installation.
Can anyone help us?
Thank's a lot
Luca Colombo

 

[DSummZZZ]

From Microsoft:

http://support.microsoft.com/kb/2704157

-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Dan Freeman]

VFP 6 SP2? **Really**???? They released SP3 a while ago.

I used to see C**5 errors pretty frequently in a VFP6 app. I eliminated 100% of them by upgrading to VFP8. (Yeah, it was a few years ago.) Seriously, recompiling the app in a newer version eliminated 100% of them.

 

[Olaf Doschke]

Wasn't VFP6 having 5 service packs? No, it was six.

Are you really referring to VFP6 at all? Even, if you are, Dve points to network problems and that may well be a reason more than VFP6. DBF handling always was and is very dependant on a healthy network, as it plays some tricks on the file system, that are easily broken, not only by the nowadays SMB2 oplock problem. The network packages getting lost, causing bursts of 0 bytes in a dbf are a known problem.

Everything has gotten better and is best at VFP9 SP2, indeed.

Bye, Olaf.

 

[Dan Freeman]

IIRC, there were at least five service packs for Visual Studio 6 but only the first three updated VFP. Still, SP3 was a big one.

I was really serious. In that job, I used to get several C5 error reports every week. After we upgraded to VFP8 (and later 9), I didn't see one AT ALL for the next six years.

 

[ajaznazeer]

Luca,

You need to install SERVICE PACK 5, and will solve your problem.

Ajaz

 

[Mike Lewis]

You need to install SERVICE PACK 5, and will solve your problem

Unfortunately, that's not so. SP5 might or might not reduce the likelihood of C0000006 errors, but it won't solve the problem.

As the others have suggested, a better approach would be to upgrade to VFP 9.0. But even that won't necessarily be a complete cure. Ultimately, the only solution is to find the underlying cause of the crash, and to fix it.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Let's look back at one fact:

>We've never had this problem on other installation.

That might be luck, but it might also be, VFP6 was used in a way avoiding the bugs causing C5 or C6 errors. Or the customer is the first one with more than X users on the data.

Dave's first answer might be sufficient to calm down the customer, and it's a good idea to recompile with a higher SP first, before moving on to VFP9. The downside to this is, you won't get SPs for VFP6 or Visual Studio 6 (I think it would be VS98), as both products are out of support.

On the other side it may cause more time lag to upgrade to VFP9, every version update had it's stricter compiler and rules, most famous may be the GROUP BY behavior change of VFP8 (or was it 9).

One thing to consider, for a quick fix:
You might get some more info on the error and it's location from a vfp6.err file. This is a file containing stack info on where the error occured, what class/prg, method/function/procedure and line, also, where from that was called, etc, the call stack. If VFP6 was installed that file would be in HOME(), on a client installation it would be where the runtime dll is or in the application folder.

If you don't find a cure, upgrading to a later VFP version, the first thing to do is copy your sources. Make a copy of the project before opening it in a new VFP version and then test compile. It'll also change forms and classes to be incompatible with VFP6, eg adding the Anchor property that VFP6 will not know. So you'll need the original project source folder, if you fail upgrading. That's not to discourage you, it's solvable, in the end you gain much better performance, cleaner VFP tables and indexes (VFP6 and 7 had more bloat in memos, eg) and remove several bugs.

You have some backward compatibility settings, eg
SET ENGINEBEHAVIOR 70
SET REPORTBEHAVIOR 80
_screen.themes = .F.

That should help you with the upgrade instead of solving all the errors and warnings of the compiler. You won't get around fixing some erros, even with legacy settings.

Bye, Olaf.

 

[Olaf Doschke]

>If you don't find a cure, upgrading to a later VFP version
That should be: If you don't find a cure, and therefore consider upgrading to a later VFP version...

 

[RobSpencer]

How much memory does the server have installed?

If it is more than 2GB, you might be in need of the fix I posted in

http://www.tek-tips.com/viewthread.cfm?qid=1721084

...but I agree with those above. Upgrading to a newer version of VFP will really help with stability.

Rob Spencer
Caliptor Pty Ltd

http://www.caliptor.com.au/

 

[lclock]

Hi all
First of all thank you
I write a wrong information, sorry, the version is VFP6 sp 5 !
We will have several user on the application but for the moment problem occurs with few user (3/4) using the application.

For the moment we made things described in Microsoft article, but we still have some crashes.
It seems that the problem occur when the application is used via RDP connection and not in lan use.
The server is a virtual server and people that manage it, has told us the the network is configured in teaming, I dont know if this may cause problem.
I will update on the situation
Thank's a lot
Luca Colombo

 

[lclock]

hi Mike,
any suggestion about
"Ultimately, the only solution is to find the underlying cause of the crash, and to fix it."
thank's
Luca Colombo

 

[lclock]

Hi Olaf, hi all
i've recompiled the application using your suggestion for backward compatibility.
I've just have one problem with a class because when i rebuild the project i've got an errore about corruopted memo file, obviously i've reopened the class, modify it but no change. But this isn't a problem.
The problem is that the application is slower than the one compiled with vfp6.5
Do you know any reason for this behaviour?
Thank
Luca Colombo

 

[Olaf Doschke]

No, you're the first complaining about bad VFP9 performance.
One thing is indeed known to be slower: Reports. Due to GDI plus rendering. But with the compatibility setting SET REPORTBEHAVIOR 80 that's not the case.

What's true for sure is, you get more advances from adjusting code with newer features, new functions, better SQL. All that of course does not happen just by recompiling. VFP6 was replaced by FP7 around 1999/2000. So your code cold have had many enhancements for the last 14 years. Anyway, youre code should run as fast as it always ran, if not faster, despite of reports.

If you get more specific, have a certain routine taking much longer, why not show it here for optimisation?

Bye, Olaf.