NET Runtime version 2.0.50727.42 - Fatal Execution Engine Error (7A05E2B3) (80131506)
What an obscure title for a blog entry eh? I just want to make sure that if someone else searches for this, they will find it because I was spinning my wheels for 3 hours researching for this fix. At any rate, here is what happened.
I have an Office SharePoint Server 2007 virtual machine that I use for private development and user group demos. Well, I opened it up today (to work on a talk for tonight, that is now canceled :)) and saw that there was an update available on Windows update (I had not opened it for about a week). How silly of me to expect that update to have been fully tested, but I digress. I forget exactly what update it was, but that is not as important as the symptom I am about to describe I installed it without thinking about it, although in hindsight, I remembered this exact same issue happening to me earlier this year, on site at a client and going thru the same thing. At any rate, hindsight is 20/20. So, after installing this update, in my case, it seemed that running any ASP.Net 2.0 application, i.e.: a SharePoint site (either Central Admin, your SSP Administration site or any ASP.Net 2.0 site for that matter that uses as an application pool identity one that does not have a profile on the server (built in system accounts are OK I think, although I have not tested this). Generally this means that that account has never actually interactively logged on to the server; the case for almost ALL service accounts. Now that is what I call brilliant design. Clearly Microsoft has received enough calls about this issue and has released Hotfix.
It's available here:
FIX: A .NET Framework 2.0 application that runs under a user account context when no user profile is associated with the user account context may crash, or you may receive an access violation error message
If the hotfix gives you an error when installing, it has done this for me, simply log on to the machine as the service account. If the machine is also domain controller you will have to manually give that account that privilege in the Domain Controller Security Policy editor. Be sure to remove this policy after the profile gets created!
Without this fix, the CLR just stops. That's right stops dead in its tracks. Nothing was working.
Well, hopefully this will save another poor soul some time.
Side note: I have used this fix before but it does not seem to be working in my VM. I suspect something else. I read somewhere that the fix is also bundled with Visual Studio 2005 Service Pack 1. I am curious as to why a framework fix would be bundled with a development tool update. At any rate, I am still fighting my virtual machine and entertaining suggestions.