Visual Studio 2010 Build Error - Exception from HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))

▲
13
▼

Recently we migrated our development environment from VS2008 to VS2010 (Ultimate).

For one solution (for now all C#, .NET Framework 3.5 and ASP.NET 2.0) which contains 6 projects VS auto-upgraded it without any problems.

The solution projects are:

  1. ASP.NET website
  2. VS2010 Web Deployment project for above site
  3. Web Services Application
  4. VS2010 Web Deployment project for above WSA
  5. A class library.
  6. Another class library.

However, when we build we have 1 error:

Could not load file or assembly 'ClassLibrary1BLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An API call exited abnormally. (Exception from HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))

After research I finally tracked this to one entry in the ASP.NET website config:

If I build with this line the problem occurs:

<identity impersonate="true" userName="DOMAIN\user" password="password"/>

However, if I comment out and build with the following line (without the supplied credentials) the solution builds fine AND then amend the web.config back to the above (with the credentials) the site runs fine - the credentials only cause a problem for the build.

<identity impersonate="true"/>

Now here is the strangest issue - the Web Services Application builds fine with the supplied credentials - the build error ONLY occurs for the ASP.NET website. This all holds true whether the projects are built individually or the solution rebuilt.

Any pointers how I can successfully build with the supplied credentials will be greatly appreciated.

c#
visual-studio-2010
exception
build
asked on Stack Overflow Jun 7, 2011 by Barry Kaye

5 Answers

▲
13
▼

Check the permissions of the impersonation user.

After just setting the flag to false, <identity impersonate="false"/>, it also came to life for me. However, once setting it back to true, it built fine, but when I loaded the site, I got:

The current identity (XN-DTDEV\Fusion) does not have write access to 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files'.

Now this machine is on a domain, and that user is local, which should have administrative privileges. When I checked back, it didn't. It looks like there is a policy re-setting the local administrators each reboot.

answered on Stack Overflow Jun 28, 2011 by mattdwen
▲
4
▼

I realize there's already an accepted answer, but for anyone else coming to this page via a search on the error code....

Review the permissions of the user that you're trying to impersonate.

In my situation, I was only getting the error on my development machine, rather then on our staging or deployment servers. (For a while I got around this by removing the 'identity' node from config in my dev environment and just adding the line in post-build so it wasn't a problem anyone other than me..

In my environment we have a specific user that all our web apps impersonate when running. I had created the user account, but hadn't explicitly set its account permissions. When I added the user as an Adminstrator on my dev machine, this problem went away completely. (Not ideal, I know, but it "works for me", and has minimal harm since that user account is locked down on our 'real' servers anyways..)

answered on Stack Overflow Nov 22, 2011 by Peter Bernier • edited Jan 30, 2013 by Peter Bernier
▲
1
▼

after changing permissions on "Temporary ASP.NET Files" you need to delete its contents and allow the new files to inherit the new security permissions

answered on Stack Overflow Jul 17, 2012 by Jack
▲
0
▼

Thanks for the reply mattdwen - unfortunately your suggestion never worked (the 'Temporary ASP.NET Files' folder permissions were correct) but did provide the hint that lead to me (HACK) resolving the problem. After reading your answer I tried the following which led me in a different direction:

(1) I successfully rebuilt the solution 3 times using <impersonate="true"/>, <identity impersonate="false"/> and <identity impersonate="true" userName="DOMAIN\different-user" password="password"/> (here "different-user" is a local admin).

(2) I then amended the web.config back to the original <identity impersonate="true" userName="DOMAIN\user" password="password"/> and ONLY rebuilt the ASP.NET website project - success.

This has led me to conclude (strongly hinted at by the original error message) that VS when rebuilding the solution is unable (for as yet unknown reason) to build one of the Class Libraries or its dependencies with <identity impersonate="true" userName="DOMAIN\user" password="password"/> in the ASP.NET website project.

The Class Library in question has a number of references to 3rd party components, Office interops, etc. which for now would be too time consuming to attempt to eliminate one by one and discover the real underlying reason.

Therefore, I have temporarily implemented the hack (cringe) to add the original user to local admins.

answered on Stack Overflow Jun 28, 2011 by Barry Kaye
▲
0
▼

If any of the solutions mentioned before didn't work, and you're using impersonation. The answer is to give permission for the user that you're impersonating access to the following folders :

  1. C:\Windows\Microsoft.NET\Framework[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files

  2. Your site directory.

also you might need to create folder as the following :

C:\Windows\Microsoft.NET\Framework\[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files\[Application-Name-Goes-Here]

But try the previous first, it worked for me.

Those two changes for granting the impersonated user permission to be able to save the temp data, and pull the dll files, and any needed files from the directories

answered on Stack Overflow Feb 6, 2018 by Mostafa Elabbady • edited Feb 6, 2018 by Mostafa Elabbady

User contributions licensed under CC BY-SA 3.0