I have a strange thing happening in the very rare case and I can't even reproduce that, because there is only few computers this error happen to. On my home PC everything runs flowlessly (in the any other OSes OK too).
Sometimes within 1-3 secs after my program exits, I can see optimistic screen saying:
Windows
A fatal exception 0E has occured at 0028:C003248C

After pressing a key everything is working as before, except I can't delete/rename my exe file.

Does someone have any idea what is going on, or where to start to find that out?
Posted on 2003-11-30 06:45:39 by masquer
My guess: your app doesn't exit properly, causes an exception, and never gets unloaded from memory. Happens sometimes. Solution: debug your exit routine, to figure out why it doesn't exit clean.

Fake
Posted on 2003-11-30 07:29:00 by Fake51
This may sound completely bizarre but I had a similar problem once and did this:

Start:

.
.
.
invoke ExitProcess,0
ret


For some reason there were times when ExitProcess didn't work (I never could figure out why not) and the program would fall into the first proc then GPF. Putting a ret after it does nothing normally as your app ends before it gets there but if ExitProcess fails the app will terminate anyway.
Posted on 2003-11-30 10:46:14 by donkey
donkey
Thanks for the hint, but still the same in my case :(

Fake51
I suppose if there is something wrong in my exit code it will reflect on all OSes, moreover I'll be able to catch an exception in a ring3 debugger (like Olly), but i don't.
I have no gdi or memory leak also.
Posted on 2003-12-01 03:04:52 by masquer
I had this problem a few times and always use 'the end' like this



start:
.
.
.
.
exit:
invoke ExitProcess,0
jmp exit

it helps to do not get any bad addresses from the stack and jump into it after ret
Posted on 2003-12-01 03:17:45 by HarryTuttle
HarryTuttle
Now I've changed ExitProcess,0 to ExitProcess,255. Not tested carefully, but it seems to work so far. And I still don't get any idea why :confused:
Posted on 2003-12-01 04:44:01 by masquer
Well, I would rather suspect that when Olly sees your exitprocess executed it then assumes your program terminated. Unfortunately, if there's data left on the stack, ExitProcess will not behave like it should, and the system probably won't be able to handle the unexpected data. Or perhaps more likely, your program IS in fact terminated, however, as HarryTuttle points out, a malaligned stack will be sure to fuck things up. Your program will be terminated, and thus the exception will not come from it, but from the kernel, even though ExitProcess might in fact return to your code. Anyway, when debugging, you can try looking at the value of the stack when starting, bpx'ing ExitPRocess and checking the value of the stack when exiting. That'll tell you.
I would suggest looking for places where you haven't aligned the stack correctly, and then going with HarryTuttles example ... you can also try setting an int 03 afther the ExitProcess call ... that will be sure to get some attention.

Fake
Posted on 2003-12-01 07:24:24 by Fake51
Fake51
In my case top of the stack on the begining is equal with that one at the end, but it could be the good point though.
Posted on 2003-12-01 08:37:38 by masquer
hrm, leaving stuff on the stack shouldn't be a problem - misaligned stack could be though.

My guess would be a buffer overflow, writing to null pointers, or something similar. 9x has next to no protection, and it's easy to write into system memory that really ought to be protected...
Posted on 2003-12-01 09:28:35 by f0dder
Remember when Exitprocess is executed it will call all dlls with PROCESS_DETACH message. So most likely the error occurs in a dll loaded (which in fact prevents the process from terminating).

Japheth
Posted on 2003-12-01 09:48:56 by japheth
f0dder
Stack is aligned. And none of the thing you mentioned isn't takes place.

Maybe if we find out who own that address it could give some ideas?
Posted on 2003-12-01 09:56:16 by masquer
A fatal exception 0E has occured at 0028:C003248C... hrm. 0E is #PF aka pagefault, right? For that to cause a BSOD, it'd have to happen in r0 code afaik. What does you app do? Which areas of the API does it deal with?
Posted on 2003-12-01 09:59:44 by f0dder
japheth
Good point, thanks! Apart from the "basic" dll set (kernel32, gdi32, user32, advapi32, shell32, ole32) I'm using Shdocvw.dll to determine IE version

f0dder
What does you app do? Which areas of the API does it deal with?

Actually nothing extraordinary - menus (ownerdrawed), couple of dialogs. The most annoying thing is that BSOD is happens only with couple of old PC's and from time to time. And I spend an ours trying to track the order of actions bringing to this error. For example, after installing SoftIce it happens a little bit rarely and with a slightly different address :(
Posted on 2003-12-01 10:20:19 by masquer
Have you looked *very* closely at all your GDI interactions? I have found win9x to be very very picky and vulnerable there...
Posted on 2003-12-01 10:24:08 by f0dder
Yes, gdi and memory leaks was the first ones I've checked. And they look different, imho :)
Posted on 2003-12-01 10:31:45 by masquer