Quote:
what are the main criteria to get the 500 Error?
You write a code that has faced most probably a runtime exception. It can range from a null object, to out of index element access, to undefined function call (in case of dynamic languages) all the way to usual but uncommon HTTP protocol violations—such as sending a response to client when a response was already sent, we face that a lot in Node.js web apps.
Quote:
Is that any chance to get the 500 internal error(When I change the server 100 times, got the error in only 1 time ) when the server is changed?
If you mean changing server in a load balanced environment, then well in this case it
can happen if your HTTP requests and their responses rely heavily on the session information and you try to access and use a session variable that was not available on this server. But this point is really a debate, and without clear evidence about your architecture, there is very little help we can provide. Your ASP.NET apps most notably handle all this information, and in most cases you can check for a value before accessing it,
if(Session["variable"] != null) {
} else {
}
But this is only the case if your code is messing with the sessions, there are kajillion other cases where your code can go wrong.
Quote:
How can I solve this issue?
As already suggested, check your logs and see what is the error, and if you don't have the logs, well you have just learnt how important logging is in a production environment. :-)
One suggestion is to test the same code in your development environment and see how the error is propagating in your application. One more suggestions is to integrate unit testing in your application and testing it completely before publishing it to the production environment, because mostly 500 errors are just normal issues that are left out during the testing phase—index out of bounds, null reference exception, etc.