Fatal error: exception code=c0000029

[newtofoxpro]

User reported, this error occurs any time anywhere in exe compiled by vfp9. Is it possible to solve this error ? And myapp.exe crash and generate error log file myapperr.log

 

[Chris Miller]

Look for a vfp9err.log file (usually in the same folder as your EXE, but it could also be redirected when users have no write permission, in /program files/applicaiton folders, for example.

This might have logged the last line executed before that error exception. Usually, it's c0000005 also known as c5 errors.

The only more general hint is to delete foxuser.dbf files that might have become corrupt and cause this, or external frx (report) or lbx (label) files.
Other general areas of problems are not updated Window OS, network or printer driver problems.


Chriss

 

[newtofoxpro]

Thank you
It is c0000029
I use config.fpw having RESOURCE=OFF
All frx included in project EXE

 

[Chris Miller]

I don't doubt it's this unusual fatal error code, but the first hint still is looking for the vfp9err.log
No matter how your EXE is named, the log file always is that, unless there is some code that renames the log file if it's found.

A C00000xy fatal error coe means an exception in the C ruintime, you can't handle this with On Error, Try..Cath or an objects' Error event. So the VFP9err.log is your only hint about when this error happens, especially if the log file always logs the same line of some method or prg of your EXE.

When you google VFP c5 you get more results than searching for c29, the nature of the errors always are some exception on the C runtime level not trappable in VFP.

An entry in the log file will log the call stack like this:

Fatal error: Exception code=C0000029 @ date time. Error log file: ...\VFP9Rerr.log
Called from - someobject.method line N {source files}
Called from - main line M {....\main.prg ...\your.exe}

Well, and that's your best hint on when what went wrong. It can be very tricky. Sometimes reproducible, sometimes not. When the line looks unsuspicious, like closing a DBF (USE) there are a lot of things done, like clearing cahce, committing changes to the DBF, triggers, so think outside of the box.

I had a reproducible case in sn OCX. So you see - don't take me too literally and say foxuser or reports are out of question. Esspecially as C29 is something I never heard of.

So, find the log file and see. There may already be multiple logs in it.
If the error is so fatal this even isn't logged you're out of luck, you'll depend on users telling what they did last, before the error happens.



Chriss