// you’re reading...


Debugging Pre-Executed (classic) ASP

The Problem

I’m sure that pretty much every RedDot CMS Web Solutions Management Server developer would have come up against some pre-executed ASP in their templates that has failed. The ensuing frustration at having no built-in method of debugging or even just getting some sort of meaningful error message out of the CMS WSMS is one of the most discussed annoyances of the product. Sure, there’s the Pre-Execute Debugger plug-in but to use that, changes must be made to the RDServer.ini file. Those changes can render a project unusable or can even crash the RedDot CMS Web Solutions Management Server …err… server (I’ve experienced both scenarios numerous times). The latter of course can be fixed by a reboot but if this is a busy production system, that’s just not practical.

Surely, there must be some way of getting those errors out of the system and back to the developer?

The Solution

I don’t know if I’m the first person to think of this but I haven’t seen it discussed before so hopefully this is useful information.

Some Background

Pre-executed ASP is rendered by CMS WSMS before being passed to IIS to run. The resulting code is passed back to CMS WSMS for inclusion in the page. Although you don’t see it, if the ASP fails, a 500 error is generated by IIS. Unfortunately, this information about the 500 error is lost as data is passed between CMS WSMS and IIS and back again.

Enter the Custom Error Page

Under IIS, it’s possible to set a custom error page for each type of error that occurs on the web server. This is traditionally used to provide end-users with a meaningful 404 page on published web sites. We can leverage this functionality to set a custom error page for a 500 error on the CMS WSMS server. In addition to this, the folks at Microsoft have seen their way clear to also provide an Error object that is only available from a 500 error and returns a bunch of useful information about the error. Thus, we can capture the error information and log it to a file.

The Process

The first thing we need to do is create some folders.

  1. Under your CMS WSMS folder (CMS/ASP), create a folder called “PreExecute”.
  2. Under the new folder, create two more called “logs” and “asp”. The machine’s IUSR account should have write access to both folders.

Next we need to set the RDExecute and PreExecute settings.

  1. In your project, under “Administer Project Settings” > “Project” > “General Settings”, select “Edit Settings” from the Action Menu.
  2. Under “RDExecute and PreExecute settings”, set the “Physical path” to “C:Program FilesRedDotCMSASPPreExecuteasp” (or the path to your folder if your install is different) and the “Virtual directory (IIS)” to “/CMS/PreExecute/asp/”

At this point, check that your pre-execution is still working in your project.

Now to create the custom error handler.

  1. Create an ASP file under your CMS/ASP/PreExecute/asp folder, call it whatever you like, something like ASPError.asp.
  2. Copy the following code into the file:
    ' Create the error object.
    Dim objASPError
    Set objASPError = Server.GetLastError
    ' Write the error information to a file (formatting of the second argument is for readability only).
    WriteToFile "C:Program FilesRedDotCMSASPPreExecutelogsPreExecuteErrors_" & Year(Now) & Month(Now) & Day(Now) & ".log", " Date/Time: " & Now() & vbCrLf & " ASP Code: " & objASPError.ASPCode & vbCrLf & "ASP Description: " & objASPError.Description & vbCrLf & " Category: " & objASPError.Category & vbCrLf & " Column: " & objASPError.Column & vbCrLf & " Description: " & objASPError.Description & vbCrLf & " File: " & objASPError.File & vbCrLf & " Line: " & objASPError.Line & vbCrLf & " Number: " & objASPError.Number & vbCrLf & " Source: " & objASPError.Source & vbCrLf & "############################################################" & vbCrLf, True
    Function WriteToFile(FileName, Contents, Append)
      On Error Resume Next
      If Append = True Then
        iMode = 8
        iMode = 2
      End If
      Dim oFs, oTextFile
      Set oFs = Server.CreateObject("Scripting.FileSystemObject")
      Set oTextFile = oFs.OpenTextFile(FileName, iMode, True)
      oTextFile.Write Contents
      Set oTextFile = Nothing
      Set oFS = Nothing
    End Function

Lastly, we need to configure IIS.

  1. In Internet Information Services (IIS) Manager, select the folder under “Default Web Site” (or whichever site you’re using for CMS WSMS) > “CMS” > “PreExecute” > “asp”.
  2. Right-click the folder and select “Properties”.
  3. Select the “Custom Errors” tab. Scroll down till you find “500;100″ in the HTTP Error column.
  4. Highlight it and click “Edit…”.
  5. Change the “Message type:” to “URL” and set the “URL:” to “/CMS/PreExecute/asp/ASPError.asp”


To test it’s pretty simple. Assuming your pre-execution was working earlier, you should be able to add some broken ASP code to your template (e.g. <!IoRangePreExecute><%= functionThatDoesNotExist() %><!/IoRangePreExecute>) and preview the page. You should get the standard (read useless) CMS WSMS error page but you should also get a log file created in your CMS/ASP/PreExecute/logs folder with detailed information about the ASP error that has occurred.


If you’re running a clustered CMS WSMS, you may want to be careful with this procedure. When I tried changing the pre-execution settings under a clustered CMS WSMS environment, it not only did not work, it also took down the publication of ALL projects. I haven’t investigated this any further at this stage, if and when I do, I’ll post my findings.


The method described above only works for Classic ASP. It would be great if someone would describe the equivalent process for ASP.NET. Any takers?

Share and Enjoy:
  • Print
  • email
  • Twitter
  • Digg
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • del.icio.us
  • MisterWong
  • Facebook
  • LinkedIn

No related posts.

About the author:

Gavin Cope is a Senior Consultant with OpenText specialising in OpenText Management Server and Delivery Server. His is based out of Brisbane with a client base throughout Australia. When not working, you'll find Gavin fishing off a kayak or working around the house - depending on which one his Wife allows ;)


3 comments for “Debugging Pre-Executed (classic) ASP”

  1. Unfortunately I wasn’t able to test this in its entirety as 6.5 doesn’t have “RDExecute and PreExecute settings”! But I was able to link the code sample up to the error handling for the CMS folder itself. Not that this is a problem, RedDot never gives helpful Internal Server errors :) . Some notes and comments:

    The code needs to be unWordPressified – replace ‘ with ‘ and “ and ” with “. Also, there is an error on line 17 – missing the S of “Set”.

    Make sure you don’t have the more specific 500;100 (Internal Server Error – ASP error) set, or if you do, override this as well!

    This solution suffers the same problem as that proposed at the Open
    Text UK Web Solutions Community Day 2009
    – Enhanced Template Design session (switching from PreExecute to RDExecute), in that the full
    source is not available and therefore the line number returned is not exactly helpful. Unless you recognise from the error the context, you can still have some fun tracking down the error in a compex template.

    My preferred method is still to drop the PreExecute tags (you do only have a single pair in your base template encapsulating everything right?), preview, view source, select all, copy, paste into your favourite text editor/IDE and save into an IIS web server (the CMS web server itself makes a good choice). Access from your favourite web
    browser. This way you have the final source in your text editor, a correct error AND line number in your browser, and the ability to problem solve the error in your IDE before mucking around further with RedDot’s joke of a template editor.

    If there is a better way, I would sure like to hear it!

    Posted by Adrian Mateljan | July 24, 2009, 10:50 am
  2. I tested this on our version 9 machine and I like it. Helps me a lot with those errors here. Thank you Gavin!
    Also I fixed the display issues by editing your post. Great stuff.
    Getting the actual error into the Previewwindow would be even better.

    Posted by Markus Giesen | July 29, 2009, 10:19 am
  3. This is a brilliant tip and it has also taught me more about the way RedDot creates pages.

    I’ve extended this example to automatically show a list errors for each day in a webpage. This means that everyone in my team can view the log files without having access to the RedDot folder. http://keithbloom.wordpress.com/2009/09/25/viewing-preexecute-script-errors-in-reddot-cms/

    Posted by Keith Bloom | October 18, 2009, 6:48 pm

Post a comment

Stay up to date! - Get notified about followup comments

If you don't feel the urge to comment but wish to stay in the loop:
Just enter your email and subscribe to new comments.

Subscribe without commenting

Recent Tweets

  • RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
  • The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
  • RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
  • Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
  • More updates...