I'm using EpiServer 8, on several servers which connected to the same DB.
On all of them I have every 1-2 seconds the following log message, which causes the log files to be huge and hard to navigate:
2015-12-23 08:19:28,728 [62] ERROR EPiServer.Global: 1.2.5 Unhandled exception in ASP.NET System.Web.HttpException (0x80004005): The file '/link/43f936c99b234ea397b261c538ad07c9.aspx' does not exist. at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp) at System.Web.Routing.PageRouteHandler.GetHttpHandler(RequestContext requestContext) at System.Web.Routing.UrlRoutingModule.PostResolveRequestCache(HttpContextBase context) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I've searched online and I found some people referenced to this problem (Even with the exact GUID), but the solutions suggested were either irrelevant or not helpful.
The GUID of the page "43f936c..." is a reference to my Root page, with ID=1. The root page is not accessible (or should not be accessible at least)
I thought it might be monitoring issue, but I get this error on my test environment which is not monitored at all. (but uses the same DB)
No conclusion to what causes this error, yet the workaround we did was disabling the log for this class (by setting the debug level to "none" for that namespace).