Kernel32 error on a quit command 1

[wjs2]

Hi all,

OK. Little history.. Running VFP 6.0 SP 5. on Windows 2000 SP3. On a 'quit' command in an exe I was getting 'variable not found error'. Running in debug mode did not produce the error. That didn't make much sense to me but went ahead and did a project refresh, project cleanup and recompiled the exe. Now I am getting

KERNEL32! 77eab2f0()
'The Instruction at "0x77eab2f0" Referenced memory at "0x00000000". The memory could not be 'Written".

Still, no problem shows running in debug mode. If I had an operating system problem or VFP problem, I would expect to see the same thing in other modules. No other modules are giving me any trouble. I'm totally lost on this one. Any Ideas?

Thanks
wjs

 

[Scott24x7]

WJS2,
Well, let me start by quoting someone who's probably dead now, "The act of observation changes the outcome". You are, at the very least, a victim of this, and anyone who's worked in Fox for long can attest to that. The error you are getting though, is a OS error, not a Fox error. Why it is occuring, is hard to guess. You may have a corrupt .SCX file.
I'd recommend a scientific approach to the problem. Without the trace on, what can you "Prove" is working? Does the screen appear at all, or does the error occur when the screen initializes? This can tell you a lot about *where* the problem occurs.
Now, if it occurs before the form appears, there are 2 key things to keep in mind here too. Don't forget about your Data Environment. Try removing the tables from your DE, and see if you get the same results. Any other clues you can give me?
Lastly, it *could* be bad memory in your machine, but I'd hold that to be very, very unlikely. Your OS, however could be corrupt. If you can compile/test your app on another machine as well, it will quickly eliminate if it's your app itself. If you get the same behaviour there, than you know you've got some issue in your app. If not, than at the very least, it's machine configuration. This will save you from tweeking lots of code that doesn't need to be tweeked just to prove whether or not something is part of the problem.

Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[wjs2]

Dear Mr. Maniac,

Good advice. I'll give it a try.

Now, If I ever wanted to quote anybody, it would be you. Hopefully before you are dead.

TVAVVQT (The Voices are Very Very Quiet Tonight)
wjs

 

[wjs2]

Very Interesting Mr. Maniac,

Enlightenment and Prestigisness are yours!

I compiled and tested this on another machine. Windows XP SP 1 with Visual Fox 6 SP 5. Different error address (which I would expect) but same problem. Next, Same machine, Windows XP SP 1, Visual Fox 7 SP 1 - clean as a whistle. Go Figure...

Now you are probably sitting there wondering what I was doing on 6 in the first place. I don't have a good answer for that. This particular exe has 24 screens, about 30 tables and 40 prgs. Didn't want any more problems than I already had but the reverse seems true. Guess it's time. 8 is going to be here sooner than I would like, but, here goes anyway....

Thanks much. Will talk to you later.

WJS

 

[wjs2]

TheManiac,

Hi. Me again. I just don't know how to give up. This is really strange and I don't really know why it works, but, here it is.

This all started when I began to resize user defined windows. I'm not going to go into that too much here. Just to let you know that was the original problem. Somewhere in the beginning of time, I remember seeing documentation to the effect that VFP would cause a Kernel error if a window, for some reason, were considered out of bounds or something to that affect (What ever that means). At one time I found this somewhere on Microsoft's web site. Can't find it now because I can't remember any of the wording. Anyway, it was passing this error off to the kernel. It was only happening to me when I was trying to do a shutdown. So, in the shutdown routine, I dummied out the actual program name being passed to the 'on error' routines. Now, if the program name that the 'on error' routine encounters is 'ShutDown', I ignore the error and just do a 'Return'. For some reason, unknown to me, this keeps the error inside Fox Pro and the Kernel never to sees it. At the same time I was discovering this, I found that my code included a 'define window' that never actually finished defining the window. This did not give a error in either VFP 6 or 7 during compile or run time. (Also, after playing around with VFP 7 for a little bit, it also came up with the Kernel32 error.)

So, two corrections... Got rid of the offending 'define window' code and also changed error handling when the system was going through shutdown.

wjs

 

[Neil Toulouse]

I read somewhere (can't remeber now might have been a thread on here) that it can also be caused by globally releasing all your objects, so the work around is to release them one by one!

Seems a PITA to do it that way if you have a number of them!

Our application does the same thing as you desribe above but only on shutdown of the app, and not all the time so our users have got used to it!!

We'll give Micrsoft a big slap on the back of the head for this one

Neil "I love work. I can sit and stare at it for hours..."

 

[Neil Toulouse]

...it's an FAQ!

faq184-2074 "I love work. I can sit and stare at it for hours..."

 

[wjs2]

FatSlug,

Thanks for that information. Will check for the global object release thingy too. Something that may be of interest to you, I was only getting errors during the time the app (exe) was being shut down. No other unhandled error conditions were appearing while actually running the program. I think the change in the error routine to check for a program name of 'Shutdown' is the one that got rid of all the errors including the Kernel32. Problem is, I don't really know how dangerous that piece of code is. Thought about checking and just bypassing certain error conditions but don't know which ones to check for.

Thanks again,
wjs