1

We have a handfull of ASMX web service hosted on two identical Windows Server 2003 boxes. The virtual directory for the web services is loaded in a DFS share, both servers point to the same share. We have a load balancer between the internet and the two web servers.

At a seemingly random interval (right now about twice per week) when a user tries to access a method on the web service, IIS returns the error: "Could not load file or assembly" for one of the assemblies used in the method call, and will continue reporting it each time the method is called until the app pool is recycled.

We haven't found any distinguishable pattern to the problem. This is what I know:

  • the missing assembly varies (but it's always a home-brew assembly)
  • the Web Service method that fails varies
  • there is no noticeable pattern to the times or intervals where the problem appears
  • there are no admin users accessing the servers when the problem appears
  • the failing method will work correctly on one server and fail on the other, even though both point to the same bin folder
  • the problem can always be corrected by recycling the app pool and making no other changes

I have enabled the Assembly Binder Log, and know that the binder is looking in the correct location for the file.

Our assemblies are compiled for .Net 3.5.

1
  • We seem to have fixed the problem by copying the Web Service files from DFS to the local hard drive, and referencing them from there, but using DFS to keep the two servers in sync would be preferred. Jul 7, 2009 at 15:45

1 Answer 1

1

We had a similar issue.

We never officially figured out what was happening but we narrowed the problem down to impersonation level in the web.config and user access to the folder hosting the assembly file.

We discovered that sometimes the IIS worker process would try and load the assembly as the person accessing the web request. We could see that the thread that was trying to load the assembly was currently impersonating a user making a request to one of the asp.net pages.

Anyway we worked around the issue by granting access to authenticated users in the domain. Hopefully you can find a better solution.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .