Geeks With Blogs
Jeff Krebsbach

In a ASP.Net web app I have a button that says "Process".  It will spawn a new worker thread that will look at a network share and process some Excel files that have been produced by a third party system.

To access the share and to use the Excel COM interop, I am impersonating an elevated user account  different than the authenticated user, using Windows Impersonation.  I then generate an Excel COM object for each Excel file, and process the files available in the network share.

Today I noticed that when the number of Excel files in the process had grown to around 30, I suddenly am getting a permissions error:

Server Error in '/excel' Application.

Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070005.

This error suggests that my current user does not have permission to open the COM object.  True, I'm running an ASP.Net web app on Windows Server, so the thread would be the server level account running the w3wp, but as before, this is wrapped in code using Windows Impersonation, so I'm doing this as an administrator account. 

Not sure what to think, my first wild guess is that somehow my impersonation context is expiring.  As an expirement I make the code stop and restarting the impersonation between each file.  The process now completes successfully.   But now I notice that I have spawned a new EXCEL process for every different xlsx file that was processed. 

After more research, the Excel App object is associated with the current user.  It appears (?) that switching context so quickly is affected Window's ability to dispose of all of those Excel instances.  More importantly: the real problem is that generating so many Excel App objects is having an effect on my impersonation, and that number of Excel App objects is affecting my ability to construct a new object and an impersonation context should never time out.

In the process file method,  every file will construct a new Excel object, then dispose and garbage collect the Excel App object upon completion.

I replace the logic to share one common Excel App object between all of the Excel input files, and the problem is now resolved.  My one impersonation object does not need to be re-created, and I only go through the effort of constructing one Excel App object which is leveraged to load the various Workbooks from.


Posted on Thursday, September 9, 2010 6:50 PM | Back to top

Comments on this post: Windows Impersonation and COM Behavior problems

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © jkrebsbach | Powered by: