Dave Burke : Freelance .NET Web Developer specializing in Online Communities

Weird ASP.NET Error of the Day: Could not write to output file

I was working on an ASP.NET 1.1 app in VS2003 this AM when all of a sudden I hit a Compile Error:

Could not write to output file: c:\windows\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\blahblah

I checked and double-checked the permissions (a-okay) and there was nothing I updated or installed recently on the machine that I could think of that would have changed system folder permissions.  The answer turned out to be the Web Application Pool identity of IWAM_MACHINENAME for the ASP.NET 1.1 applications throwing the error.  Changing the identity in the pool to NETWORK SERVICE did the trick.

How or why IWAM_ no longer could write to the system folders I don't know, but I'm not alone as this has happened to others, too.  A quick Google Groups search will prove I'm not making it up.



Technorati Tags:

Comments (5) | Post RSS RSS comment feed

Posted on 2/15/2006 10:33:00 AM by Dave Burke
Categories: .NET
Tags:

Related posts

Comments (5) -

2/15/2006 12:39:46 PM Permalink

Two things to check:

1) Did you run out of disk space on that drive?
2) Could you have a disk quota setup that limits the amount of storage the IIS account can use?

hope this helps,

Scott

scottgu@microsoft.com |

2/15/2006 12:53:00 PM Permalink

Scott,  Always wonderful of you to stop by!  Nope, neither are applicable.  Just checked.  To be honest, I don't know anything about a disk quota for IWAM_USER, but I setup the server and never knowingly came across any such quota.  Definitely don't think that's an issue.

I went through the Eventlogs for the last couple of days.  Nothing ASP.NET or IWAM_ or similarly related.  No clues or cookie crumbs whatsoever.

We're good at the moment though, so unless IWAM_ going silent is an indicator of impending doom of some other sort, all is well...

Thanks!

daveburke |

2/15/2006 1:32:01 PM Permalink

I have seen something very similar to this on a development system that had the Indexing Service turned on and the ASP.NET Temp directories NOT excluded from the indexing.  I think stopping the Indexing Service would tell you right away.

Rob Bazinet |

2/15/2006 2:59:30 PM Permalink

Rob, I sure appreciated your input.  I never would have thought to think of the Index Server issue.  I did remember seeing the "Index this folder" on the Microsoft.NET folder tree earlier, so I cleared that setting on the entire tree.  Went back with the IWAM_ user on the application pool with an app pool restart, but the problem persisted.  

I went into Services and checked the Indexing Service. It wasn't even running!  

Or was it?...

But I thought you were onto something and I wanted to stay with it.  Back in IIS Manager I looked at the websites and saw that they were being indexed.  How they were set that way I have no idea.  I cleared that and restarted the site.  Error persisted.

I rebooted the server earlier in the day when I first encountered the problem, but while pursuing your suggesting I hadn't yet done an IISRESET.  Now after removing indexing from the temp folders and the site folder, I IISRESET, set the App Pool identity back to IWAM_ -- and IT WORKED!

So in conclusion (first, THANK YOU for the great suggestion), maybe it was the fact that the temp folders were being indexed and/or possibly the site directories themselves.  Bottom line, clear those index settings, iisreset, and enjoy ASP.NET running in IWAM_ again!

It was a kick working through your suggestion, Rob.  Big thanks to you!

daveburke |

2/15/2006 6:52:06 PM Permalink

Dave - Great to hear it worked.  I suffered from a similar problem a while back, very annoying to try to solve.  

Rob Bazinet |


Powered by BlogEngine.NET 2.0.0.36
Theme by Dave Burke