• RedDot CMS Blog
• 15.11.2019
• EN

rdb: 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 Files\RedDot\CMS\ASP\PreExecute\asp” (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 Files\RedDot\CMS\ASP\PreExecute\logs\PreExecuteErrors_" & 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  
     Else  
       iMode = 2  
     End If  
     Dim oFs, oTextFile  
     Set oFs = Server.CreateObject("Scripting.FileSystemObject")  
     Set oTextFile = oFs.OpenTextFile(FileName, iMode, True)  
     oTextFile.Write Contents  
     oTextFile.Close  
     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”
    

Testing

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.
 

Warnings

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.
 

ASP.NET

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?