503 error IIS7 – no log file

It looks like the temp IIS profile that is used (normal for IIS) can't be created. I bet you will have the same issue if you create a new user and try to use it. In other words, the root issue is not related to IIS. I don't know what symimv.cat is, but nothing turns up on a google search. Is that something custom that you or your corporate team have installed?

In other words, it sounds like something amiss with your default user profile.

You've mentioned "IIS Log File" (singular), but there are always two logs you need to evaluate:

• W3SVCnn logs (C:\Inetpub\Logs) from the website worker process, and
• HTTPERR logs (C:\Windows\System32\Logfiles\HTTPERR) from HTTP.SYS, which routes requests to worker processes and provides a kernel-mode queue designed to buffer clients from worker process changes (like recycling)

503s are far more likely to appear in HTTPERR logs, along with a reason for failure, because they're more likely to reflect a failure of HTTP.SYS to communicate with the worker process (or a queue overflow, which amounts to a similar thing).

See also http://support.microsoft.com/kb/820729 - not sure why there's a "Fix it" when the article describes what the logging does and (at the bottom) the reasons it might log for a failure.

A bit more

There are two queues in most app frameworks - the HTTP.SYS request queue (in kernel mode) and a user-mode request queue. If a user-mode framework (like ASP.Net) queues requests internally, then the failure of a worker process will result in a 503 (or at best a 500) for all requests queued within it, causing HTTP.SYS to regard those requests as abandoned and unsalvageable.

If your app is failing with unhandled exceptions, you need to fix that - there's nothing the IIS architecture can do to insulate {batches of in-flight requests} from {the app lunching itself} and you will get some form of error communicated to the client - Recycling ensures there's a new worker process ready to serve the second try.