Filling C:\Windows\Temp!

B

Bradley Plett

We have a web service that gets quite a few hits. We are noticing
that C:\Windows\Temp is filling up with temporary DLLs that never get
cleaned up. They certainly appear to be related to the web service. I
need to know either 1) how to prevent all the DLLs from being created,
or 2) how to get .Net to clean up after itself (i.e. delete the DLLs
after using them). I think I understand why the DLLs are being
created
(http://groups.google.com/group/microsoft.public.dotnet.framework.aspnet/msg/8e995c00ff9849c6),
but I have no idea how to solve the problem. We have, on occasion,
found over a million files in that folder! Any thoughts on how I can
prevent this?

Thanks!
Brad.
 
B

Bradley Plett

I'm sorry, but I don't think this is a particularly satisfactory
answer. There has to be a way to fix this. How does ASP.NET run
really BUSY sights if this is the behavior?

By the way, we've also found an accumulation of files in "C:\Program
Files\IIS Resources\DebugDiag\Logs". This one is less severe, but
still - how can we turn this off?

Thanks!
Brad.
 
B

Bradley Plett

I think I've figured out where these are coming from. We are doing an
XSLT transformation in our web service. Our XSLT has some .Net script
in it. I believe each time the XSLT is loaded, it gets recompiled
into C:\Windows\Temp. Though this post may be premature, at least
this makes sense to me and it's something I can almost certainly fix.

Brad.
 
B

Bradley Plett

By the way, we've also found an accumulation of files in "C:\Program
Files\IIS Resources\DebugDiag\Logs". This one is less severe, but
still - how can we turn this off?

Ignore this. I believe this is being caused by some diagnostic
software that Operations put on the machine.

Brad.
 
T

Teemu Keiski

I understand but see following:
http://msdn2.microsoft.com/en-us/library/182eeyhh(vs.80).aspx

a.. The XmlSerializer creates C# (.cs) files and compiles them into .dll
files in the directory named by the TEMP environment variable; serialization
occurs with those DLLs.

Note
These serialization assemblies can be generated in advance and signed
by using the SGen.exe tool. This does not work for the server side of Web
services. In other words, it is only for client-side use, and for manual
serialization.


The code and the DLLs are vulnerable to a malicious process at the time of
creation and compilation. When using a computer running Microsoft Windows NT
4.0 or later, it might be possible for two or more users to share the temp
directory. Sharing a temp directory is dangerous if the two accounts have
different security privileges, and the higher-privilege account runs an
application using the XmlSerializer. In this case, one user can breach the
computer's security by replacing either the .cs or .dll file that is
compiled. To eliminate this concern, always be sure that each account on the
computer has its own profile. By default, the TEMP environment variable
points to a different directory for each account.

If it would follow the normal <compilation tempDirectory="tempDirectory">
way which is been there all the time, this would be easy. But web services
use XmlSerializer which again uses TEMP environment variable (because
XmlSerializer can be used outside ASP.NET / web services).


--
Teemu Keiski
AspInsider, ASP.NET MVP
http://blogs.aspadvice.com/joteke
http://teemukeiski.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,754
Messages
2,569,521
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top