I have one problem which I am not able to understand.
There are some unhandled exception in my asp.net application which I believe setting some of static variable in my class to null.
I believe this is because unhandled exception is recycling the application pool.
If I use Apllication_Error in global.asax , will that stop recycling of app pool?
If I use Application_Error in global.asax , will that stop recycling
of app pool?
No, Application_Error might or might not even be reached, if Application Pool recycles due to hard crash.
It seems that you do not have any logging framework in your application. One thing you can do at this point is to see the errors in Event Viewer.
For example,
FYI: To view friendly error messages, you might want to add error logging to your application such as NLog, Log4Net or Elmah.
Related
I've notice that on the production server, my asp.net 4.7.2 application is very slow. By debugging I've found that in global.asax the Application_start and Application_end is called on every request, causing a recompile of the application each time and slowing down the response.
I0ve test it on several servers and the behaviour is always the same.
Running the website on localhost in IIS (not iis express) this not happen.
How can I check why Application_End is called and from where?
Debugging in VS the Application_end stacktrace is empty, I cannot see from where is called.
Thanks
The problem was cause by Kaspersky Endpoint Security for Windows Server version 11.0.0.480.
For some unknown reason it act on w3wp.exe causing the application restart on each requests. The only way to solve the problem is excluding w3wp.exe from the monitored applications/processes.
There are many circumstances when the Application_end will be called, such as application pool's recycle, web.config file's change, or bin file's change. For more detailed information about Application_end be called you need to check the Event log in the sever.
I am facing an issue while trying a simple ASP.NET default application on the server. This is a fresh new server.
I get the error - 4010 An unhandled security exception has occurred.
There are no error details to it.
I have seen few websites which tried to relate the error to cache, however i don't have any cache in use.
On the local machine everything seems to be working fine. Any suggestions ?
I had this issue today and it was due to my asp.net application wanting to write to the Windows Event Log. The Event Source didn't exist and my application didn't have the permissions to create it so it errored with this message:
Event code: 4010
Event message: An unhandled security exception has occurred.
The fix for me was to create the Event Source and my application started working. I followed the steps from the below answer to manually create the Event Source via the command line:
How to create Windows EventLog source from command line?
In IIS, try increasing your site's .NET Trust Level to Full (internal).
You should try to enable trace or custom logging and see what the exception stack trace is.
ELMAH or Glimpse are useful if you don't have access to the production system.
http://www.iis.net/configreference/system.webserver/tracing
You might try to change the trust level from medium to high in the Web.config.
http://msdn.microsoft.com/en-us/library/tkscy493(v=vs.85).aspx
Microsoft has this info for how to log these exceptions to the Application log
unhandled exceptions cause ASP.NET-based applications to quit unexpectedly in the .NET Framework
I had to change the trust level from medium to high in the Web.config and solved issue
Reason :Full: Specifies unrestricted permissions and grants the ASP.NET application permissions to access any resource that is subject to operating system security; all privileged operations are supported
I initialize static state of my web applications in Applications_Start method (Global.asax). At that time I write a message to log. Suddenly I've realized that this method was called every 10 minutes.
Is it corrected behavior? I expected ASP.NET to keep its applications at least for several hours.
Your expectation is incorrect. This is set in the application pool setting in IIS configuration. I think the default is 20 minutes. This can be changed to 0 if the application pool should not be recycled.
This is not typical. Something is causing it to restart and it should not be doing so this frequently. Check out How to find out why an ASP.NET web application is being restarted question to see how you can log details on why it restarted.
Since you are writing out log files, maybe you are writing them to a location that is be monitored for recompilation, which will cause a appdomain restart. Check out the post What causes an application pool in IIS to recycle?
Check out this article on iis.net to see the default for recycleing. It is 29 hours, so unless this setting has been changed for you, something else is causing it, not the automatic recycle.
We are encountering a strange phenomena in our production environment, every few hours the application kicks all users out by ending their sessions with Session_End event and fires Application_End event.
In our log, all the user's sessions are closed on the same mill-second.
We encountered this problem in our Test environment but only on rare occasions, and we could not duplicate this.
Everything else seems fine, other application running on this server works fine, there is no memory leak or CPU overuse. The application is based on ExtJS version 3.3, NHibnernate 3.2 and ASP.NET 4.0.
It doesn't seems like a Timeout error, some of the users worked for only several minutes before the session end.
Has anyone encountered similar problems?
There are a couple of reasons why an application pool recycles (and thus ends all open sessions and ends the application). See http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx for a complete overview.
We had a similar problem in a production environment once. The reason for the recycle was the virus scanner that touched the web.config on each scan which made the application pool recycle. Try to disable the virus scanner on the server or exclude the application directory in the virus scanner.
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
This post: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx gives you a way to catch the application end event with more detailed logging. This might help you to find the cause of the recycle.
I develop and debug an ASP.NET application with VS 2010. My ASP.NET application holds some connections to other applications on other machines. When I stop debugging, I want these connections to be released. If this doesn't happen, these other applications fail and I have to restart them.
In the end I will store my termination code in the Application_End method in Global.asax.cs, but this one is not called when stopping debugging.
Is there a way to terminate the debugging of my ASP.NET application so that not everything is killed at once, but so that one last method is called in which I could add my termination code?
I'm not sure what your problem is but probably...
You initialize your debug session by pressing F5 and thus debugging through cassini. This way when you end your debug session the application is terminated.
If you have a configured IIS application you could simply attach to the running process - it's usually "CTRL + ALT + P" - choosing w3wp.exe (mind the checkboxes on the bottom to be checked). This way your app won't be terminated on ending the debugging session.
Does it solve your problem?
I misunderstood how debugging an ASP.NET application works. I thought the moment I stop debugging (by pressing Shift+F5) the ASP.NET application is terminated and no further line of code is executed. It was my explanation to why the Application_End method is not called.
But in fact the ASP.NET application goes on when the debugger is detached and therefore the Application_End method is not called.