>During my testing, I find that the messagebox() is not the worst of the possible problems.
>I have one big window (modeless) that references a Public object oPassword, in one of the control methods.
>So, when I try close the application, while this window is still open, I get an error that "oPassword is not defined". Which tells me that the object oPassword is destroyed and then the application tries to self-close this window.
>The conclusion is that the code, above, that closes all open windows, IS important.

That's the problem with framework entanglement. On startup, you can't instantiate object A because it relies on an instance of object B, which in turn can't be instantiated because it requires object A... refactoring both is the only way out. Luckily, there isn't much to refactor, because you just added this interdependence and it immediately stopped working, so you didn't have the time to add anything else on top of that.

It goes in reverse on the way out, as you just described. If framework requires some object to be there (say, an error logger or event handler or any other global piece), specially if it calls its methods from any of the destroy(), cleanTheHouse(), BeforeSeppuku() or any such method, than that object can't be destroyed yet, or you get in exactly this kind of trouble.

Generally, it's enough that those objects be of any lightweight, possibly non-visual class, so they don't get a position in .Forms collection. And, it's mostly a good practice to retrace your steps backwards - what was created first, is destroyed last... a kind of a LIFO stack.