Fatal error: Exception code=C0000005

[Jay9988]

Hi all,
I have Foxpro app, and one of the module is to generate report
on one PC, there is persistent error like this

Fatal error: Exception code=C0000005 @ 02-07-2024 01:40:30 PM. Error log file: E:\MCM\VFP9Rerr.log
Called from - frmlapdepr.pgf1.page2.cmdok.click line 32 {e:\mcm\frmlapdepr.sct e:\mcm\frmlapdepr.sct}
Called from - main line 241 {E:\MCM\main.prg e:\mcm\mcmmenu.exe}

But, on another PC is running well.

Anyone knows what is the problem ?

Many thanks

 

[Chris Miller]

There are several things mentioned you should look into:
1. the file E:\MCM\VFP9Rerr.log
2. frmlapdepr.pgf1.page2.cmdok.click line 32
3. main line 241

Why don't you also post those things?

As you say it's only on one PC, but persistent there, it's likely a corrupted file only on that PC. Which file could be pointed out by one of those files and lines of code you didn't post, so please do so and we might be able to tell.

In general, I can only give the advice to be a detective and follow pointers you have, the above 3 pointers in this case. That message alone is just telling there's a fatal error. If you think we're mythical mages who can tell more from that alone: No.

Chriss

 

[Chris Miller]

Bte, I guess line 241 of main.prg is READ EVENTS but it might be something else. Line 32 of the click event of the cmdok control (button, I aassume) on page2 of pageframe1 in form frmlapdepr is most interesting.
And the file E:\MCM\VFP9Rerr.log is to be found on the PC having the error, of course. It's also still opf interest, even if the last code running will give the most important indication of whats causing the ftal error, reproducible, by telling what file could be corrupted - a local table, for example or a report or whatever that line of code works on/with.

Chriss

 

[Mike Lewis]

I can't add much to what Chris has written regarding this specific error. But, in general, these are some of the things to check when you encounter a C5:

1. Corrupt index or memo files. Check by trying to open and browsethe relevant DBFs in the command window. If necessary, reindex the DBF and PACK MEMO. Failing that, restore from a backup.

2. Anti-virus program. Try excluding all VFP-related data files (DBF, CDX, etc.) from real-time scanning.

3. Corrupted printer driver. (Less likely.)

4. Dangling object references.

5. RETURN from inside a WITH / ENDWITH.

6. Corrupt resource files. Try closing VFP, deleting all FOXUSER.* files, and restarting VFP. Note that this will cause the loss of your IDE settings (such as the position of the command window and the presence of toolbars).

There are many other possibilities, but the above are probably the most common.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

To add to what Mike said, there's no reason to just step through his 6 points already before looking into the directly indicated files and code lines from the error message and the vfp9.err file.

It's obvious those lines themselves work on other PCs, there's no build/syntax error, but as I already indicatde the line mentioned as last executed could be a REPORT FORM command and the report it uses is perhaps excluded from the EXE and is having a corruption on that one PC and not on others.

So also add 2 more things

1. The EXE itself, make a comparison with the EXE of your development computer or any of the working clients. It might be that the corruption is exactly in the poiunt line 32 of the cmdok button is within the EXE of that PC only.
2. reports used by the EXE

About some of his points:
Anti-virus would cause problems in random places when scanning for virusaes coincides using the file, i.e. executing code in an app/exe/frx, modifying data in a dbf. Likewise a foxuser.dbf corruption can cause problems anywhere randomly. Those are not corruptions leading to reprodicble C5s. A reproducible C5 rather points out a file corruption of one specific file only.

Chriss

 

[Jay9988]

Hi Chriss, Mike

thank you for your inputs.

The text I firstly posted is from the vfp9Rerr.log, and after look into the source code:
1. The error message: frmlapdepr.pgf1.page2.cmdok.click line 32 is actually this statement

 msql="select d.no_aktiva,d.no_seri,t.nama,t.umur,t.harga,t.tgl_beli,SUM(d.expense) expense,convert(0,decimal(15)) jual,t.metode,"+;
	     "ifnull(s.no,0) no,ifnull(s.expbln,0) expbln from dmesin d join "+;
 	     "(select no_aktiva,no_seri,concat(trim(barang.nama),' ',barang.tipe) nama, max(no)/12 umur,"+;
		"convert((expense+bookvalue),decimal(15)) harga, min(tanggal) tgl_beli, 2 as metode from dmesin "+;
		"join barang on dmesin.no_aktiva=barang.kd_brg where kddivisi=?xxdivisi group by no_aktiva,no_seri) t "+;
		"on(d.no_aktiva=t.no_aktiva and d.no_seri=t.no_seri) "+;
		"left join (select no_aktiva,no_seri,no,expense expbln from dmesin where tanggal=?thisform.txttgl.value and nonaktif=0 and no_aktiva in("+mmesin+")) s "+;
		"on(d.no_aktiva=s.no_aktiva and d.no_seri=s.no_seri) "+;
		"where d.kddivisi=?xxdivisi and d.tanggal<=?thisform.txttgl.value and d.nonaktif=0 and d.no_aktiva in("+mmesin+")group by d.no_aktiva,d.no_seri"
      SQLEXEC(xcon,msql,"casset")

and the line 32 refer to the SQLEXEC statement

2. the error message: main line 241 is the "READ EVENTS" statement

thanks

 

[Chris Miller]

Jay9988,

okay, I expected tthe command to be about an FRX or DBF, not SQLEXEC. So it's not pointing out a specific project file you could check, but the EXE on that one computer could differ from the EXE you provided. Such a change can always happen no matter if the drive it's stored on is a hdd or ssd, a hdd sector or an ssd page can always read out something else than what was written to it.

So if thinking about fatal errors as poiniting out a file corruption, candidate files are now the EXE itself. The ODBC driver, even the VFP9 runtime and C++ runtime. Foxuser.dbf stores settings for browse of tables. there could be a record about "casset", but I don't see how that would be read for SQLEXEC, it would be read for a browse of the result.

Your line numbering could be off, though, as the fatal error is about the EXE run, not about the current version of your source code. One thing to do, therefore, to be sure line numbers of source code matches exactly that of error logs is to make a backup of your whole project when you release an EXE. But lets assume while the source code changed since you released the EXE, this click method didn't change since then.

Then there's just one more question:
How reproducible is this error, really? Do you always get C5 everytime you click that button on that computer?

First answer that, if only for yourself. If there is reproducability the files to check are quite a lot and instead of checking each single file, first give it a shot to delete foxuser.dbf on that one PC. Then reinstall ODBCD driver and your software after a deinstallation, so all involved runtime and ODBC driver files get recreated from the setup, that obvioulsy has correct files, otherwise all other PCs would have the same errors.



Chriss

 

[mJindrova]

Hmm,

If SQLEXEC() cause C5 periodically, then problem will be (mostly) in used ODBC driver.

If SQLEXEC() cause C5 randomly, then problem can be anywhere:
- damaged DBC container
- damaged used VCXs
- called API functions with wrong buffer length
- 1., 3. - 6. by Mike Lewis


mJindrova

 

[Chris Miller]

The bottom line of such fatal errors is, they don't come from the usual VFP error mechanism. The errors are so fatal that not even that gets triggered, so neither a CATCH block, an ON ERROR routine nor the system VFP error message appears, the VFP runtime crashes and the C5 is reported from the C++ runtime, ie. the mentioning of VFP9R in the VFP9Rerr.log filename does not state it's from the VFP9R.DLL, but about a problem crashing the VFP9R.DLL and detected by the C++ runtime.

The reason corrupted files can cause this is because any command/function that expects a specific helathy file strcuture from a DBF, FRX, etc. can crash by wrong pointers or simpyl wrong byte values that then lead to access of wrong file positions or memory adresses, etc.

You see it is really important to know whether a C5 is reproducible, and whether it only happens at one feature. I had C5 caused by OCXes, too. There are tons of reasons but mostly connected to a corrupt file or driver or any file that's not having data or code (entry points, for example) as expected.

I also mentioned ODBC already, the only doubt about that I would have is, that it only happens at this specific SQLEXEC. Since you don't use something exotic there, but an SQL Select, corrupt ODBC driver would cause C5 all over the place not only there.

The other bottom line is, if you don't find the actual file causing this, doing a clean uninstall and reinstall of your software and all components should fix whatever regards only that installation, so if you don't want to play detective to get to the root of the problem, that's simple enough to do. Just take care of any valueable local only data/configuration that should be kept - albeit it has the corruption itself. Important is to not just install again, but actually first uninstall also the ODBC driver to get to a clean initial situation. Setups based on Installshield Express would just see an already existing application.exe, runtime dlls and keep them untouched, which would obviously undermine getting all files replaced that could be corrupted by what's clearly healthy within a setup that creates working installations on other PCs.

Chriss

 

[Dan Olsson]

In my limited experience of C5 errors (my users don't get them a lot), the line numbers in the error log aren't very useful.
The crash could be at the same place, but line numbers can be different despite that.
A reboot of the offending client usually fixes the problem.

 

[Chris Miller]

the line numbers in the error log aren't very useful.

I can't confirm that. It was very useful to find an error related to an OCX or an FRX corruption.

We already pointed out if you get errors in many places, the actual problem might be with foxuser.dbf or another file that's not only used in one location of code. As Jay called it a persistent error it's still not absolutely clear whether all of them alway happen in the same line of code. If that would be a REPORT FORM it would be totally plausible and the cause is not that the REPORT FORM command is broken or has options that cause the C5 but it's the FRX that causes this.

So never underestimate the information you can get out of the line number/code location, especially not if you get persistent (always the same) error message.

Chriss

 

[Jay9988]

Hi all,
Yesterday, after looking into the line 32 which was triggering error, and found only simple "SQLEXEC", I tried to reinstall the mysql odbc driver, and it solved the problem.

Same suggestion from Chriss, and mJindrova..

Thank you all for your inputs.

 

[Chris Miller]

Dan, see?

If you think about error messages pointing out something wrong in the line of code, that's not already found while compiling, then you think wrong when it comes down to C5 errors.
Nevertheless here it was an exmple of pointing out a problem with a file, in this case the ODBC driver DLL, obviously.

I think that's why most people say in their opinion the line number is useless. It's clear the SQLEXEC() call is okay and when you know how sql query errors don't cuase an exception and error handling you know it points in the direction of that. Could still also be the EXE is corrupt at that specific line.

Just one question, if you don't mind, Jay. Was that your only SQLEXEC in that application?

What I hint at with that question, although also already said is, that when you get multiple C5 in multiple locations but look into them and find it's always SQLEXEC, you can become very sure it's ODBC mishap.

Don't just throw away what the erros in C5 logs point at, never. Just know that you have to look at this from another perspective as usual errors.



Chriss

 

[Jay9988]

Hi Chriss,

My application has a lot of SQLEXEC command, and only the SQLEXEC in line 32 is causing error so far..

thanks

 

[Mike Lewis]

Well, the line 32 SQL is quite long and complex. No doubt the ODBC driver and the back-end database can both handle it, but the length and complexity might be factor.

Just a thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Okay, Jay, then the corruption in the ODBC may be very specific to something in that query, like the convert call. A file being corrupt can still be generally usable but cause the fatal error just in special cases. Or that user just did use that query and stopped using the application. There's no other PC involved in this, so you get no further C5s from them.

That installing the ODBC driver helped is proof enough that this time it was an ODBC driver corruption. You never assume this from an SQLEXEC alone, as that compiled and works on other PCs, so the way this gives the valuable information to you is realizing what a fatal error means in contrast to a normal error.

I hope I made clear how you have to look at different things and ask different questions about the line erroring.

Chriss