Post mortem exception

[oex]

In fact I do not know how to be arrogant but unfortunately I am often perceived like that by humans.

:bg

[jj2007]

Still, fun to see that you can exit an application and afterwards you get banged over the head...

A process doesn't end after you ExitProcess(), only after all the handles have been closed.  A process actually HAS to stay active, so that something else can read the exit code you returned via Exitprocess() in the first place.

Red,
When launched normally, the exe successfully deallocates with HeapFree, then prints "debug ok" and then crashes with a box.
When run with Olly, it exits fine and terminates at KiFastSystemCallRet, with Olly indicating the correct ExitProcess return code, -111 in this case.
It's pretty futile to argue since heap corruption is the cause, and the bug needs to be fixed anyway. But lessons might be that a) HeapFree returning TRUE is no guarantee that your heap is ok, and b) that there is life after ExitProcess :bg

[hutch--]

 :bg

There is a special skill to arrogance based on experience and allowing how long I have been writing software for Windows I can probably safely boast that I have had more GP faults than most other folks around. The flip side of the phukups is I am reasonably good at finding them.  :bdg

[redskull]

b) that there is life after ExitProcess

There's not just life after ExitProcess(), there's an entire advanced civilization of issues that can go awry.  Some examples to cook your brain: The system brings all the other threads to a halt, so anything they are waiting on is stuck in limbo; for instance, image thread B has issued a ReadFile(), and is then signaled by thread A's ExitProcess(); what happens to the resulting APC if the process is gone?  Also, all the DLL's get their DETACH message, so any loaded DLL has a chance to wreak any havoc it likes, and deadlock/crash anything it wants.  Also, if some other program is using WaitForSingleObject() to wait on the process in question to terminate and then plans to use GetExitCodeProcess() to see what went wrong (which requires the handle), how long must the operating system keep the handle valid?

Big Fun!   :toothy

-r

[dedndave]

i dunno about you having more GP faults than anyone
i thought c0000005 was my name for a while, there

[donkey]

Also, if some other program is using WaitForSingleObject() to wait on the process in question to terminate and then plans to use GetExitCodeProcess() to see what went wrong (which requires the handle), how long must the operating system keep the handle valid?

Hi RedSkull,

When you open a handle to the target process or create the process as a child process which returns an open handle the system increments the reference count on that process. The system will not clean up the process structures until after your application closes that handle and the reference count drops to zero. As with any object, it is only completely destroyed once ALL handles referencing it are closed, including those in other processes. Once all open handles to the process are closed the system will perform a cleanup of the process structures.

Edgar