I have a client that is running a classic asp site on IIS7. In order to see any errors from the classic asp pages, I modified the IIS7 Error Pages to point 500 and 500.100 errors to a special classic asp page that finds the last error and then appropriately logs it for the future (pretty much what Elmah does for asp.net). What we are seeing on IIS7 is an occasional error message from the exception logging classic asp page itself. And it appears it is for the 500 errors; 500.100 errors seem to get logged without any problems.

So two questions:

  • How can I cause a plain old 500 error (not 500.100) on this website to test the classic asp page exception logging?
  • Is there a better way to capture and log exceptions from classic asp pages in IIS7?
+2  A: 

Two questions - two answers:

  1. you should be able to raise an error with the following err.raise nr, source, description
  2. The error handling you are using (modifying the error pages) seems to be a common way for classic asp apps.
1. Would generate a 500.100 script exception not the plain 500 error.
+1. i did not know that.

Write intentially bad code. Create a connection to a db that doesn't exist. Instantiate an object that isn't installed. Create a string variable that is a word and multiply it by 5.

Joel Etherton
These would all generate 500.100 errors. Not just plain old 500 errors.
Jeff Widmer
When you get down to it, they really appear to be the same. The 500 vs 500.100 is just a matter of the resulting error file. According to this article: http://support.microsoft.com/kb/261200 , it looks like the 500 is what is served if the 500.100 is not available.
Joel Etherton