Quote Originally Posted by Ramil View Post
OS Kernel (what is it, by the way in your analogy?) would either terminate the buggy application or do nothing. It won't help the USA.exe to start working normally.
2.
COM object A has a reference to COM object B while COM object B has a reference to COM object A. No external references remain. A COM object is released when its reference counter is zero. Since object A still has at least 1 valid reference as well as object B, their reference counters cannot be zeroed. The memory won't be released until the system restarts. That IS called a memory leak. Fairly common among inexperienced programmers. And you cannot clear that memory because OS kernel won't let you. General protection fault on early systems or access denied on newer ones is guaranteed.

Back to the first off-topic. What makes you think that the USA 'developers' had put all these exception handlers before they compiled the whole stuff? What I saw in the past several weeks was more like 'dirty hacking' than even debugging.
1. I meant you could run your code at the same privilege level as the kernel, and use kernel functions as well as accessing kernel objects directly. Then you usually have no problems with doing whatever you wish to any processes, etc.

2. As you might have noticed, I've been talking about a bit more low-level programming than COM programming. After all, you can always tell the OS a certain range of memory is to be freed.

Then, well, speaking in terms of COM programming, such memory leaks do really look lame. But what makes you think the developers are so unexperienced? And why do you think they would use COM model?