I have been debugging this issue prior to bugging it with the product groups and have some information about the cause.  The issue occurs due to the way that autorun opens Internet Explorer and the fact that we use separate processes for tabs and to define protected mode.

When autorun is given an htm file to open, it checks in the shell associations what application is the default application to open the file.  When it find this, it uses a technology called Dynamic Data Exchange to open the file.  This means it opens Internet Explorer and then passes it a data structure of the parameters it needs to open (in this case the path to the htm file). 

With the new process per tab architecture, we initially open a broker process which then opens a new tab process.  Due to the way we are opening using DDE, we play it safe and make the new tab open in low integrity mode (ie protected mode).  The path to the htm file is not in protected mode, so we must then open a new tab process to open this in.  It is here that the problem occurs.

Before opening the new tab process and redirecting to the CD path, we make a security check that we have a good path to open and call into the shell to parse the path we have.  It is here that fail to bind to the CD drive due to low integrity mode and as a result the redirect fails.  The tab process we were going to open does not get opened and our current tab process exits (as it would if we did open the new tab) and therefore the broker process, with no open tabs also exits.  This is why there is no error message.

The reason that adding the my computer zone to protected mode (as per the workaround you were given) works is that if its in protected mode then it does not needs to redirect to another tab process, therefore not doing the cd check into the shell.  Another scenario I tested was autorun from a memory stick – this works due to the fact that we do not have to bind to the CD drive.   We also do not see this issue if the IE process is already started – autorun with IE already opened simply opens a new tab.  This is also due to us again not having to call the redirect code. 

So there are several factors that are needed to see this issue:
1.       We must have protected mode enabled in a zone other than the my computer zone (as it is by default)
2.       IE must be started using DDE (as autoplay does)
3.       IE must not be running at the time that autoplay starts
4.       The htm file must be on a CD
5.       The OS cannot be XP or Windows 2003 since they do not have UAC which is needed for protected mode

In the development of a product, as many scenarios as possible are played out both automatically and manually to check for any issues.  Code reviews and continued checks by senior developers are done on every change made during development.  Once we start to enter beta testing, the product is tested not only by the product team, but internally all are encouraged to use the pre-released product and report any issues they find in everyday use.  There are so many potential different uses of products that field testing is extremely important.  Whilst still in beta, the product will get a public beta release which lets the general public use the pre-released version and also report any problems that they see.  We go through several beta releases, constantly updating until we go to RTM, but still issues are going to slip through and this is true of any product no matter who writes it. 

If a problem isn’t encountered or no one tells us about it, then it will be missed.  I searched our database and this is the first report of the problem, which is surprising seeing how easy it is to reproduce. 

I have now bugged the problem and this will then be investigated by the product group for inclusion in a future release.  By bugging it, it also ensures that this will be a scenario that will be tested against in future releases.