>Dragan,
>About two years ago I had a very similar problem which took may (grey) hair out.
>You decribe exactly the same sequence, and had to do with the COMCTL32; Now look at a similar thing happening on setup-errors (look at the threads a little higher), also noticable on other forums; I talked to MS about this, who admitted that "timebombs can be there" but didn't recognize my problem (so, similar to yours, if not exactly the same);
>
>One by one PC's start falling over, even PC's at home never used, and worse, the PC's at customers. My priceless solution back then :
>
>Create the smallest distribution set you can imagine, put the expected problem-maker in there (for me this was COMCTL32) and run this setup on the concerning PC (if I'm right, in the end all of them). And now all works fine.
>Note that two years ago I did all there was to do (admitting OCXes to the registry explicitly in many ways etc. etc. Nothing helped.
>The setup luckily did ...
>
>Now hope it helps for you too.
>
>Note : If it is really the same problem you should be able to notice it by starting VFP.EXE, create a Form and drag an OCX-object onto it. In my situation even that didn't work anymore (and did for years, and should of course).
>
>Once you find the solution, please let me (us) know; I'm shivering already.

Part of the problem is that everything works fine here, and works fine on one machine I was able to connect to using PCAnywhere. It's the machines which are inaccessible to me - in three different states. Searching MSDN I found there's maybe a way to fix this one, because it's part of the (guess what), IE5 setup. They even have a separate download to upgrade just this one, at http://support.microsoft.com/support/kb/articles/Q186/1/76.ASP
So this may help (or not), but still I hate it when it comes down to things like this. I'm still curious as to the probable cause of this, and I just wish I could reproduce a problem.

What sort of time-bomb are you mentioning? A clockwork one, or just a dll made of not-so-rust-proof steel?