I have an asp.net MVC 5 framework that runs a bunch of sites and we have an issue where as the site runs for a few days(sometimes even hours), it begins to error about being able to load views (The partial view ~/Views/Comment/ExtraHeaders.ascx was not found or no view engine supports the searched locations the following locations were searched).
The error also occasionally says "The file '/Views/Cobalt/Shared/Error.aspx' has not been pre-compiled, and cannot be requested" This view file is also definitely there
We do precompile the views before deploying. This error persists after an app restart, but goes away when redeploying the code. Any ideas about how to debug the underlying problem?
I am going to try and do a byte by byte comparison of every file the next time it happens to see if maybe some corruption is happening?
Related
I've been having an issue with MVC 5.2.3 (and earlier versions back to about 4) using Razor (VB.NET) views where
1) I can't reliably set breakpoints inside a View (doesn't work most of the time even if VS doesn't give me a warning that it couldn't bind, which it often does)
2a) When it hits an exception within a View, the debugger often opens the wrong file (can inspect values fine though!)
2b) Examining the stack trace for the exception shows the wrong file!
3) Occasionally an exception thrown within a View doesn't resolve to any View file at all and the debugger just says it can't find the source and the stack trace doesn't show any file
I've had this on multiple computers running VS2013 and 2015 on Windows 7 and 10. I'm just using the default routes that were set up with the original project template. This has been going on for probably a couple of years now. I think it is affecting multiple projects, but I've mostly been concentrating on one recently so can't remember for sure.
Sample stack trace - note the "no relevant source lines" and the "OperationsMatrix.vbhtml" which is underlined - there is no reason that view should be included and it definitely isn't rendering if there is no exception! The correct view is "AnalyticsReport.vbhtml" (line 122) which is being partially rendered from within "SalesAnalytics.vbhtml" (at line 108). The debugger is also incorrectly opening "OperationsMatrix.vbhtml" on an irrelevant line (the only thing on that line is an End Sub for a lambda method).:
I've had a look in the temp file it is referencing in the stack trace and that seems to be just be referring to OperationsMatrix.vbhtml, so that file seems to be wrong too, but it doesn't actually seem to be executing that, because I can fix the bug in AnalyticsReport.vbhtml and the exception stops occurring.
After changing some code and changing it back again (ie. effectively the same code), it is now generating the following:
Note that there is now source code referenced at the top (from the wrong file - LiveStock.vbhtml) and that file is now appearing near the top of the stack trace instead of one not being found. Lower down, OperationsMatrix seems to have disappeared and it can't seem to find anything for that one. I am pretty sure that the top one should be AnalyticsReport and the lower one should be SalesAnalytics. I'm pretty sure that it should be mapping to Layout.vbhtml as well, which doesn't seem to be working in either of these tries (not noticed/can't remember if it ever does). It seems to be fairly consistent in terms of it either doesn't find anything or it finds another file in the same folder.
I've just had another look at the generated files in the temp folder for that second stack trace. App_Web_grga51wc.3.vb appears to be for a different file and App_Web_grga51wc.1.vb seems to be the one for _Layout.vb. The file refs in the #ExternalChecksum and #ExternalSource directives appear to be correct, so I don't think that the problem is in the code generation or mapping the code from the generated file back to the original using the #ExternalSource directives. The problem seems to be that it is mapping the IL compiled code back to the wrong generated source file (presumably a problem with the PDB file?). I have no idea how or why this is happening, or why it seems to only be affecting MVC projects and nothing else.
For absolute clarification, the views which are being returned are apparently random from the same folder and are not referenced in any way by the view with the bug causing the exception. They are generally not designed to be partial views and often it wouldn't make sense to use them as a partial view - they are usually full, unrelated views which are designed to be used completely independently of the one which is being called.
I've also tried deleting the whole temp folder that it is using and obviously clean and rebuild etc. Also tried disabling the VS profiling tools.
nb. there is no consistency with which view is incorrectly opening. A different one was being opened when I had a slightly different exception a few minutes earlier.
Any ideas?
Finally worked it out!
In the web.config file for the site (the root one, not the one in the Views folder) the \ had an attribute as follows: -
assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
I have removed this attribute and it seems to be debugging fine now! It looks like VS2013 added this when I initially created the project and it has been corrupting the DLLs/PDBs that are generated and messing up the debugging.
To clarify, if anyone else has the problem, the compilation opening tag now just looks like
<compilation debug="true" targetFramework="4.5">
I have this Grails 2.2.3 (still...) application. It's a normal app using GORM, and SpringSecurity, nothing unusual.
The only unusual thing is when the app goes in production, the webapps/ROOT folder (where the app lives) is populated by a lot of other folders in the root of it. These folders do not contain stuff that is needed by Grails, but for reasons I find shameful ^_^; , they have to be there. I'm talking about a huge amount of directories with various depths.
The big problem here is at Tomcat restart, the whole process hangs with a beautiful:
INFO: Initializing Spring root WebApplicationContext
and takes like 40 minutes to proceed further.
Using JVisual, we noticed the reason was a huge amount of directory listing and file reads.
We never reproduced this behavior locally, until we noticed this thing. We recreated an environment full of directories and violà, same behavior.
Now:
anyone can confirm my guess is right
any idea on how I can "disable" this search on uninteresting paths (or tell which are interesting)
Ok, I can confirm this is actually happening. When Grails starts, it looks into its webapp directory and scans looking for something. If the directory is stuck with content, it'll hang forever.
We didn't find a solution to this problem but found a way to move those resources away from the folder.
So keep in mind: always keep your webapp directory clean form stuff that can be moved elsewhere.
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.
We're trying to publish our little web app here.
I've done it several times in the past and it worked pretty well.
As the tags states, its a MVC ASP.Net project coded with VS2008.
Other interns worked on that project and we tried to re-publish again and we have this error:
[IndexOutOfRangeException: Index was outside the bounds of the array.]
XXXXXXX.XXXXXXXRepository..ctor() in
E:\XXXXXX\YYYYYYY\ZZZZZZ\XXXXXXXRepository.vb:11
XXXXXXX.HomeController..ctor() in
E:\XXXXXXX\YYYYYY\ZZZZZZ\Controllers\HomeController.vb:10
Problem is, the path pointed here E:\XXXXXXX....*Controller or *Rep is located on the LOCAL machine where the dev. is made. It's as if something was hardcoded directly in our local machines in the Rep.VB and HomeController.VB. It should point in the path where we published the whole project wich is not E:\XXX\YYY\ZZZ
Anyone ever encountered this ?
Thanks alot guys
Have a nice day.
-Tom
That is just information about where to search error in source files, so those paths have nothing to do with error appearance, they just for debugging purposes - if you will compile from your machine, they will change, but error will not dissapear.
Error message indicates, that problem is, that code tries to access array element, which is not there (let's say array has 1 element and program tries to access second one).
I have a site that is taking around 20 seconds to load every page (no matter what it does)
So i put in a /scripts/test.html that isn't part of a route and it still takes this long... no db hit nothing.
I renamed the web.config to _web.config and it loads instantly, rename it back... back to around 20-30 second load times.
Running the application locally... i put a breakpoint on the RegisterRoutes in the Global.asax.cs and ran that... /scripts/test.html does not hit breakpoint normal site does (site loads instaly fast locally on the same database/code)
Server is Mosso IIS7/SQL Server 2008 Cluster
The site is being hit pretty hard... ANY help please? or things to test/debug?
Few things to try:
Try taking a look with FileMon/ProcessMonitor and see if there is a ton of disk activity.
If the above is not an issue, install an instance of Dot Trace by Jet Brains. Profile the app and see if there is some memory or performance issue that is not apparent on your local box.
I saw another related issue that was solved by disabling IPv6, maybe try that.