Steve Hebert's Development Blog

Steve's Blog - From .Net to dotMath and everything in between.

System.IO.FileNotFoundException - running a webservice on Win 2k3

Here's a bizarre problem I ran into today that I thought could use some google-juice.

I am getting the following error when I try to run a new webservice I have
placed on any one of 4 windows 2003 servers. (Running under ASP.NET 1.1)

To minimize the problem, I created a simple webservice called "TestApp" that
exposes [ public int Add( int x, int y ) ] as the lone method on the service.
I create a simple installer package for the msi and run it on the server.

When I go to http://.../TestApp/Service1.asmx, the generated page and test
page appear fine. When I run the test page, supplying values for x and y and
upon pressing the submit button, I receive the error message listed below.
Each time I execute this, the name of the dll changes.   The names of the
dlls seem pretty random, none of them turn up on a Windows Live or Google
search. The text of this message is completely unformatted - no headers like
the sample methods normally show on errors.

The problem appears to be security related - when the application pool user is given admin rights the problem goes away. Based on the call stack, I'm guessing the CLR JITter is running into problems with the provided assembly. (?)

System.IO.FileNotFoundException: File or assembly name kciklf5_.dll, or one
of its dependencies, was not found.
File name: "kciklf5_.dll"
   at System.Reflection.Assembly.nLoad(AssemblyName fileName, String
codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean
throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
Boolean stringized, Evidence assemblySecurity, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef, Evidence
assemblySecurity)
   at System.CodeDom.Compiler.CompilerResults.get_CompiledAssembly()
   at System.CodeDom.Compiler.CompilerResults.get_CompiledAssembly()
   at System.Xml.Serialization.Compiler.Compile()
   at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings)
   at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[]
mappings)
   at
System.Web.Services.Protocols.XmlReturn.GetInitializers(LogicalMethodInfo[]
methodInfos)
   at
System.Web.Services.Protocols.XmlReturnWriter.GetInitializers(LogicalMethodInfo[] methodInfos)
   at System.Web.Services.Protocols.MimeFormatter.GetInitializers(Type type,
LogicalMethodInfo[] methodInfos)
   at System.Web.Services.Protocols.HttpServerType..ctor(Type type)
   at System.Web.Services.Protocols.HttpServerProtocol.Initialize()
   at System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type,
HttpContext context, HttpRequest request, HttpResponse response, Boolean&
abortProcessing)

=== Pre-bind state information ===
LOG: Where-ref bind. Location = C:\WINNT\TEMP\kciklf5_.dll
LOG: Appbase = file:///C:/Inetpub/wwwroot/TestApp
LOG: Initial PrivatePath = bin
Calling assembly : (Unknown).
===

LOG: Policy not being applied to reference at this time (private, custom,
partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/WINNT/TEMP/kciklf5_.dll.

Published Jul 07 2006, 03:18 PM by shebert

Comments

Wyatt Barnett said:

The issue here is that in .NET 2.0 the CLR creates compiled clases to handle Xml serialization, and it puts them in the default windows temp folder (ie C:\WINNT\TEMP). So, things blow up as the web user accounts do not, by default, have access to this folder. The solution is to explicitly grant read/write/modify/delete priviliges to the service accounts running the service.

# July 7, 2006 4:59 PM

Brian Schmitt said:

The ASP.Net worker process creates those randomly named dll's when it compiles your application. If you were to 'restart' the worker process, you should get a new filename, b/c it recompiles the assemblies.

Make sure that your ASP.Net wp has access to the winnt/temp folder this is where they are executed from.

# July 7, 2006 9:41 PM

AsbjornM said:

You say that the name of the dll changes, but is the dll file created?, according to the logs above it looks like it tries to find the dll file, but if it cannot create the file in that folder, how can it find the file?

How are the rights in your c:\wint\temp folder?, in an normal installation the aspnet user has full rights there so it can compile this file. The filename would change each time, since the file obviously is not created the previous time.

# July 8, 2006 4:31 AM

Jim L. said:

Steve,
A quick google does appear that this is indeed a permissions issue. Most posts referenced (obviousy) the ASPNET account not having proper permissions to the assembly.

This particular post was similar to your problem and had several suggestions , some of which you've tried.
http://www.systemwebmail.com/faq/4.2.1.aspx

found this on MSKB
http://support.microsoft.com/default.aspx?scid=kb;en-us;322886

Hope this might help

# July 8, 2006 10:44 AM

Mark Brackett said:

I'd think it'd have something to do with the following:
a. Dynamic compilation - that'd be why the dll name is random
b. Changes from ASPNET to NETWORK SERVICE account for IIS6

Note that I've never really fully grokked the dynamic compilation model, but as a first step, I'd try granting NETWORK SERVICE modify rights on the C:\WINNT\Temp folder (where the DLL seems to be getting compiled to). If that doesn't do it, try running FileMon from SysInternals.com and seeing what file access is being denied.

I *thought* that dynamic compiles occurred in one of the Framework directories, but I could be wrong...Perhaps it's a setting in machine/web.config?

# July 9, 2006 9:31 PM

Riaan Hanekom said:

I had this error a while ago - it's quite a recurring thing with webservices and complex types. Basically, the XML serializer is "choking" on the incoming (or outgoing) xml.

The assembly name is a temporary assembly generated by the XML Serializer. Check your classes being exposed for out of the ordinary things - jagged arrays (and multi-dimensional arrays) are big culprits.

There's also a tool out there called XMLPreCompiler that actually tests whether your types are truly serializable. See it here : "http://www.sellsbrothers.com/tools/#XmlSerializerPreCompiler"

# July 11, 2006 4:46 AM