'SFPageService does not exist' errors in Windows Application Log after SF 4.4->5 upgrade
On July 5th, I upgraded our production server from 4.4 to 5.0.2860.0 SE. Since then I'm seeing lots of errors in the Windows Application log that look like to following:
An unhandled exception occurred and the process was terminated.Application ID: /LM/W3SVC/4/ROOTProcess ID: 3972Exception: System.Web.HttpExceptionMessage: Directory 'E:\Web Sites\NLGSitefinity\SFPageService' does not exist. Failed to start monitoring file changes.StackTrace: at System.Web.FileChangesMonitor.FindDirectoryMonitor(String dir, Boolean addIfNotFound, Boolean throwOnError) at System.Web.FileChangesMonitor.StartMonitoringPath(String alias, FileChangeEventHandler callback, FileAttributesData& fad) at System.Web.Caching.CacheDependency.Init(Boolean isPublic, String[] filenamesArg, String[] cachekeysArg, CacheDependency dependency, DateTime utcStart) at System.Web.Caching.CacheDependency..ctor(Int32 dummy, String[] filenames, DateTime utcStart) at System.Web.Hosting.MapPathBasedVirtualPathProvider.GetCacheDependency(String virtualPath, IEnumerable virtualPathDependencies, DateTime utcStart) at Telerik.Sitefinity.Abstractions.VirtualPath.SitefinityVirtualPathProvider.GetCacheDependency(String virtualPath, IEnumerable virtualPathDependencies, DateTime utcStart) at System.Web.ResponseDependencyList.CreateCacheDependency(CacheDependencyType dependencyType, CacheDependency dependency) at System.Web.HttpResponse.CreateCacheDependencyForResponse() at System.Web.HttpCachePolicy.UpdateFromDependencies(HttpResponse response) at System.Web.HttpCachePolicy.UpdateCachedHeaders(HttpResponse response) at System.Web.HttpCachePolicy.GetHeaders(ArrayList headers, HttpResponse response) at System.Web.HttpResponse.UpdateNativeResponse(Boolean sendHeaders) at System.Web.HttpRuntime.FinishRequestNotification(IIS7WorkerRequest wr, HttpContext context, RequestNotificationStatus& status) at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)Here's a bit more info:
The error also causes the SF webapplication to crash. I can cause the problem 9 times out o 10 by navigating to www.mywebsiteurl.com/default.aspx.
My masterpage did have a link that pointed to "~/default.aspx" which I've since changed to point to "~" which has made it less likely the crash would occur. However, the masterpage hasn't changed since we went live over 4 months ago and I did not have this issue with SF 4.x so it does appear to have something to do with SF 5 changes. Regardless, shouldn't SF handle page routing for default.aspx?
Hello Steve,
One way to resolve this is by deleting Default.aspx. What I recently tried, and it seemed to work was to create the SFPageService folder in the root of the project and that looked like it solved the problem without having to delete the Default.aspx file.
Greetings,
I'm getting this too now. Not very excited about it. It seems to happen as soon as I add in a second register tagprefix etc at the top of a base.master page. And yes, as soon as I create the folder,.. .it works. Is there anything I can do about this or am I bandaiding this?
Hello,
I have not encountered this error in the newer versions, would it be possible to share some more information how you reproduce this on your end, please?
Regards,
Atanas Valchev
Telerik