WIN2K - I'm really pissed

Results 1 to 4 of 4

Thread: WIN2K - I'm really pissed

  1. #1
    David Highlander Guest

    Default WIN2K - I'm really pissed

    Has anyone else had the problem with Win2K in that when you have errors on a page, instead of actually showing you the error and telling you what line of code it is, all you get is the default page that says "There were errors on the page and it cannot be displayed" <BR><BR>It is driving me crazy! If I don&#039t know where the error is, how can I fix it?!

  2. #2
    Steve Cimino Guest

    Default RE: WIN2K - I'm really pissed

    Go to They give you the fix for the Win2K problem. Basically, it has to do with your reponse.buffer, but I&#039ll let them explain it more in detail for you.

  3. #3
    David Highlander Guest

    Default Steve - I didn't see the article?

    Was it an article or did you just want me to send them my question? Unfortunetly the ask a question is down right now. :-(

  4. #4
    Steve Cimino Guest

    Default Here it is

    Although not what I rembered of it, perhaps it doesn&#039t apply to your problem. Maybe you also need to turn off the option "Show friendly HTTP error messages) in IE. Anyways, maybe this article will help a bit.<BR><BR>------------------------------------------------------------<BR><BR>A100217: Response.Write Statements DO NOT Show Up Under IIS 5. <BR><BR>A common technique for quickly debugging simple ASP pages is to place Response.Write statements at key points in the code. Then, when an error occurs in the page, the output from all the debug statements prior to the point of failure shows up in the browser, followed by the error message generated by the ASP interpreter. While this method works fine under IIS 4/ASP 2.0, by default it will not work under IIS 5/ASP 3.0. This article explains why, and describes how to make IIS 5 behave the same as IIS 4 in this respect. <BR><BR>Under IIS 5, when an error occurs in the processing of an ASP page, the only output sent to the browser is the error page. This is because, under ASP 3.0, the Response.Buffer property is set to True by default. The effect of this setting is to cause all ASP-generated output to be buffered on the server rather than being immediately sent to the client. The buffered output is only sent to the client when execution of the page is complete, or an explicit call to Response.Flush is made. In the event of an error however, the ASP engine clears the buffer and sends only the error page to the client. Thus none of the Response.Write debug statements (or indeed any of the HTML code in the page) ever reach the browser. <BR><BR>Further complicating this issue, is that there is a quirk concerning the default value of Response.Buffer that is dependent on how Window 2000 is initially installed on your computer. If you do a clean install, the ASP 3.0 default value will be True (as expected). However, if the install is an upgrade, the ASP 3.0 default value will be False (not as expected!). <BR><BR>Fortunately, it is an easy matter to set the buffering to be false. While you are debugging, simply placing the following statement at the top of your ASP page: <BR><BR>&#060;% Response.Buffer = False %&#062; <BR><BR>For more details of the Response.Buffer property, refer to the online DevGuru ASP Quick Reference which now covers ASP 3.0. <BR>The Guru<BR><BR><BR>Comments or Suggestions?<BR>Copyright 2000 by Infinite Software Solutions, Inc.<BR>Trademark Information <BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts