ImageResizer app crash

Question

We had ImageResizer throw the error shown below, and subsequently I believe the app pool crashed and a new one started... This, in turn, also caused a massive queue of images to build up and the service was down for half an hour. Anyone seen this before?

Note, we've also seen a few "access denied" errors from ImageResizer in the EventLog for images with "images" in their filename. Unsure if related.

Any thoughts would be much appreciated

Exception information: Exception type: ImageProcessingException Exception message: Failed to acquire a lock on file "E:\images\1d\3a05214b1dfa98e41d04ed86db6c3f6e600347e92a1b102016e8eac5ee15a9ed.jpg" within 15000ms. Caching failed. at ImageResizer.Plugins.DiskCache.DiskCache.Process(IResponseArgs e)
at ImageResizer.Plugins.DiskCache.DiskCache.Process(HttpContext context, IResponseArgs e) at ImageResizer.InterceptModule.HandleRequest(HttpContext context, String virtualPath, NameValueCollection queryString, IVirtualFile vf) at ImageResizer.InterceptModule.CheckRequest_PostAuthorizeRequest(Object sender, EventArgs e) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Answer 1

"Get it running tips"

First, make sure you're running ImageResizer 3.4 or higher, as it works around some new bugs in the 4.0 CLR related to file flushing.

Second, make sure there is no anti-virus software that could be scanning or locking the files at runtime (AV likes to scan files as soon as they are written, locking them until they 'pass').

Third, make sure there is no impersonation happening - cached files are written by ASP.NET, but served by IIS, so multiple user accounts can get involved.

Fourth, make sure your server's disk enables async writes. This reduces file handle contention tremendously. You can additionally enable asyncWrites in ImageResizer's DiskCache to help.

Diagnosing the culprit

If this is happening with a specific set of files (and broken images don't 'fix' themselves shortly), you probably have permanently locked files from a unexpected death of the worker process. Often the only solution for those files is to reboot the server, but try the Sysinternals tools first. Sysinternals Process Montior, Process Explorer, and Handle can be useful in diagnosing what process caused the locking (but not which software within the process, of course).

Diagnosing what killed a process isn't terribly difficult, but can be time-consuming. Turn on failed request tracing (and if that doesn't help, use adplus to get a crash dump). The crash dump can identify the culprit, but failed request tracing can only give you good hints. In the crash dumps I've inspected, ImageResizer is almost never the cause, as it uses very good memory management and tends to manage errors well. If you have any other software that deals with imaging, you might consider disabling them.

As ImageResizer is a web service, you can typically run it in a sub-application that uses a different application pool. If you're suspecting ImageResizer of being the problem, this is usually the quickest way to be sure. Of course, if your images are served out of multiple root-level directories, this can take some time since you would have to create multiple sub-applications.