Mitchel, thanks for the hint on AutoUpgrade, I have adjusted it in my web.config. Hopefully, it will prevent this error from happening in the future.

Looks like a bug in DotNetNuke, though a hard to reproduce one. I think this is a critical problem, however rare it might be, the consequences are quite serious to ignore it. Maybe someone from core team could comment on this?

Here are some more details:

 - in my case it was happening on production machines, where there was no development or debugging done (unlike jascht's case who observed it after crash in debuggers)

 - the changes in web.config are:

    1) new key appeared in <appSettings>:    <add key="InstallationDate" value="6/7/2007" />
    2) in <system.web> / <machineKey> -- changed values of  the validationKey and decryptionKey attributes.

- a new folder appeared: Config\Backup_2007671850\  (I guess the number after backup is year/month/day/hour/minute), this folder contains two files: web_.config and web_old.config (respectively, current and previous versions of web.config), the owner of the folder and the files is NETWORK SERVICE, so I assume it was created by DotNetNuke.

So it looks like the normal procedure but triggered under wrong circumstances. I don't know how it is implemented in the core, but maybe the DNN starts installation process when it cannot connect to database, which might be just a transient error and happen due high load on database? Should there be some proof from such situations? E.g. automatically turning off the AutoUpgrade after successful intial installation?

Thanks.

--Daniel

Hmm, this is strange, my web.config did not have this key for a couple months, and the site was working just fine. Also, after I restored the changed web.config back to the old version, the site continued to run without InstallDate key, and does not trigger installation wizard any more (until the next time, which is unpredictable, and that's what worries me).

--Daniel