This project has moved. For the latest updates, please go here.


Session service is modifying the memory of the Classic ASP runtime


Initial description was:
"I am trying to use this service with classic asp running jscript. Platform running on Windows 7, IIS 7.5. It is able to retrieve the session object, but it doesn't appear to be updating the db when the session is updated from the app. There are no entries/errors in the logs. Any suggestions would be appreciated."

Updated description:
Steps to reproduce:
<%@ Language= "Javascript" %>
var Session = Server.CreateObject("AspSessionService.AspSession");
Session("TEST") = "Hello World"
=> Displays "test" in lower case whereas

<%@ Language= "Javascript" %>
Session("TEST") = "Hello World"
=> Displays "TEST" without changing the case (expected behavior)

The Homelidays Session Service is modifying the memory of the Classic Asp run-time because with Session("TEST") = "Hello World" it modify the memory of the string "TEST". Classic Asp shares the same string instance for all the "immediate" strings (e.g. "TEST" directly written in the ASP code).

file attachments

Closed Jun 15, 2014 at 8:34 PM by Yanal


Yanal wrote May 12, 2014 at 3:19 PM


Thank you for trying session service

Session Service works fine on Windows 7 x64. This is the configuration me and my team are using.
Our production is running Windows 2008 R2 x64.
I don’t know if this help but the database is not updated when the session is updated but once at this end of the page life cycle as described in the schema in attachment.
The log files are stored in the installation folder (e.g.: C:\Program Files\Homelidays\Session Service) but the account that runs the Classic ASP application pool needs to have write access to the Session Service installation folder.

Did you follow all steps described in :

If you like I would be glad to have a Skype call with you (I am not selling anything ;-) where I can show you how to install/configure the session service and answer any question.


gtibbitts wrote May 13, 2014 at 12:36 PM

Thank you for responding. I am running SessionService on Windows 7 x64. My website is running in 32 bit mode. I know session service is working to some degree because it creates a session in the database. I also know that the service is able to write logs to the log file because during the installation process errors were written there before I had my connect string for the db correct. It appears to be set up correctly. The only things it doesn't do is after I update the session, and I have navigated to a new page, the session variables aren't written to the database and not accessible to the next page. I am using jscript, not vbscript and wonder if this has been tested with jscript or if there are other configurations that need to be made for the page life cycle events to properly trigger the session service write to the db. Let me know of any additional information you have that might help. Thanks,


Yanal wrote May 14, 2014 at 9:22 AM

Hello Greg,

I have never used jscript. Maybe it doesn't work with jscript but only with vbscript.

Could you try it with vbscript ?

If it works on vbscript but not on jscript I can add a method to allow you to save the session at the end of your jscript.


wrote May 14, 2014 at 12:12 PM

Yanal wrote May 14, 2014 at 12:12 PM

Hello Greg,

I spent some time this morning to try to reproduce your issue without success.

Here are the step I followed:

1) I have downloaded the version 1.0.11 of the Session Service in x86 from codeplex: => Even if you are running a 64 bits operating system you should use the x86 because you told me that you are running in 32 bits mode in you last message.
2) I have then opened C:\Program Files (x86)\Homelidays\Session Service\AspSessionServiceConfig.xml and C:\Program Files (x86)\Homelidays\Session Service\AspSessionServiceConfigAdo.Net.xml and set the login/password for my local tempdb.
3) I have created a new web site + a new app pool (integrated mode + 32 bits mode) => cf screenshot in attachment.
4) I have written file a Classic ASP JScript file ("TestJScript.asp") with the following content:
<%@ Language= "Javascript" %> 
    var Session = Server.CreateObject("AspSessionService.AspSession");
    Session("TEST") = "TEST";
5) I have called this page: http://localhost/TestJScript.asp
6) On the [tempdb].[dbo].[Session] table I can see that the session has been saved.

Some questions:
1) Did you install the x86 version?
2) Could you make sure you did a var Session = Server.CreateObject("AspSessionService.AspSession"); in your script in order to override the Session provided by IIS (both object share the same methods).
3) Do you see the [dbo].[Session] in the database (TempDb by default if you did not change it)?
4) What happens if you call Session.Save() at the end of your script?


gtibbitts wrote May 14, 2014 at 2:10 PM

Thank you for your time. I spent some time further debugging and found that it is indeed saving the session. It appears the COM object is doing something strange that was throwing me off the actual error. I have an if statement that sets a value in the session like this:

if (ResultSet("TEST") == "TEST") {
Session("TEST") = true;

What it is doing is lower casing anything in double quotes on the page, so none of the string compares return a match and the Session variables aren't set. So print("TEST") actually prints test. This only happens if I instantiate the AspSessionService.AspSession. If I comment that out, my print("TEST") prints TEST. Very strange, but that is indeed what is happening. Let me know if there is anything in the source code you think might cause this.

Yanal wrote May 14, 2014 at 3:56 PM

Hello Greg,
<%@ Language= "Javascript" %> 
    var Session = Server.CreateObject("AspSessionService.AspSession");

    Session("TEST") = "TEST_UPPER_CASE"
    Session("test") = "test_lower_case"
    Response.Write("<BR \> Session(\"TEST\"): ")
    Response.Write("<BR \> Session(\"test\"): ")

    Response.Write("<BR \> BLAH")


Session("TEST"): test_lower_case
Session("test"): test_lower_case

It looks like not all double quoted strings are lower cased but only the strings that are used as a key of the Session collection.

So I look at the code (AspSessionService\AspSessionContents.cpp) and in the STDMETHODIMP CAspSessionContents::put_Item(BSTR Key, VARIANT Value) fundtion.
This function called behind the scene when adding a (key, value) pair in the session object.
The first statement is a BstrToLower(Key);
So I think that the string that Classic ASP is passing to my COM component is the same string instance everywhere in the page where we use "TEST".
I was not aware of this behavior of Classic ASP. I think I need to copy the key in an other string instance before lowering the case.

I need to fix the code and release a version.

Thank you for your feedback.


gtibbitts wrote May 14, 2014 at 3:57 PM

Another note on this. It only lower cases the string if I have a session variable with the same name as the string being compared. So the following:

prints 'TEST' without the single quotes of course.
But after I assign this session variable:
Session("TEST") = false;

prints 'test'

And it is the same with a comparison.

if (Session("TESTVAR") == "TEST") compares Session("TESTVAR") to "test"

I think it might be in the lower casing of the keys that is somehow affecting the strings on the page. I'm going to comment out that code and see if it fixes the problem.

gtibbitts wrote May 14, 2014 at 4:02 PM

Sure enough. If I don't do the BstrToLower, it doesn't mess with the string casing on the page. Must be something weird about how MS handled the scripting with jscript. Is there a particular reason you lower case all of the session variables?

gtibbitts wrote May 14, 2014 at 5:04 PM

Thanks for being so responsive!

Yanal wrote May 14, 2014 at 5:07 PM

I am doing a lower case to have the same behavior as the IIS Session:
Session("Test") is the same as Session("test") with the IIS session.

The goal is to switch from the IIS Session to the Homelidays Session Service with minimal code change on the ASP side.

This issue is not related to JScript, it's also happening with VBScript.


wrote May 14, 2014 at 5:11 PM

wrote May 14, 2014 at 5:22 PM

wrote May 14, 2014 at 5:24 PM

wrote May 14, 2014 at 5:29 PM

wrote May 14, 2014 at 5:29 PM

gtibbitts wrote Jun 9, 2014 at 4:54 PM

Any idea when a release will be out with this fix in it?


wrote Jun 9, 2014 at 8:28 PM

Yanal wrote Jun 10, 2014 at 2:47 AM

Hello Greg,

Thanks for the reminder, I have just:
  1. Fixed the issue
  2. Run the non regression tests
  3. Released version 1.0.12
Please note that those binaries won't work on operating system earlier than Windows 7 x64 SP1 as described here

Unfortunately I don't have an earlier version of Windows anymore to build binaries that works on every operating version of Windows.

I hope this helps.

gtibbitts wrote Jun 10, 2014 at 5:28 PM

I installed the update. I am using the x86 version. I couldn't tell from the description if it could still be run as a 32 bit app, but the code was provided, so that is what I used. I copied the dll's over the old ones and the following is the error I get:

Microsoft JScript runtime error '800a0e7a'

Unknown runtime error

/index2.asp, line 9

Active Server Pages error 'ASP 0194'

OnEndPage Failed


An error occurred in the OnEndPage method of an external object.

Yanal wrote Jun 11, 2014 at 6:41 AM

Hello Greg,

What operating system are you using?


gtibbitts wrote Jun 11, 2014 at 9:00 PM

Windows 7 64bit. I installed the 32 bit installer though as our app is still running in 32 bit mode. I was able to solve the problem. For whatever reason, the installer removed my configuration when it installed the new version into the Session Service x86 directory it created.

Yanal wrote Jun 11, 2014 at 9:08 PM


I am glad to see that you manage to fix the issue.
Indeed the installer is not very smart it drops all the file he created even if you have update them like config files.
This is why you lost your configuration.
The the installer installed the new files with the default connection strings.
I am not going to try to fix this installer issue so please remember this behavior for next time :-)


wrote Jun 15, 2014 at 8:34 PM

wrote Jun 15, 2014 at 8:34 PM