"Object reference not set to an instance of an object&q

[swong]

Help!! After installing VAult 3.02 with no indicated problems, when I try to log in using the Admin tool using "admin" or any other login, I get the following error:

"Server was unable to process request. --> Object reference not set to an instance of an object."

I've tried everything I can think of: reinstall Vault, authentication using Network Service/local account/active directory account, re-register ASP.NET, etc.

System: Dual 1.6 GHz P4/1 GB RAM/2x70GB SCSI HDs running Windows Server 2003 fully updated & patched, .NET 1.1, IIS 6.0, active directory connected (not domain controller), SQL Server 2000, wwwroot is on D: drive not C: (Vault installed on d:\inetpub\wwwroot\vaultservice)

The sgvault.log file shows the service starting up with no problems and no errors logged. The main system event log shows successful logins to the SQL server from the Vault impersonation account but it doesn't seem to log it every time I try to do something in Vault.

The SQL server enterprise manager shows the database being created and populated with the a login for the impersonation account being generated.

There is one error right away which prevents the web service from running. The web.config at the wwwroot is set to "Minimal". I had to uncomment the permissions in the web.config file in the Vault install directory to give it "Full" permissions to fix this.

The Vaultservice home page comes up no problem. The web service page comes up after the previous error is fixed. I don't know how to test the web service, but the "Ping" command seems to work properly.

The "Web login" page comes up, but any attempt to login simply returns "login failed".


Aieeeeeee!!!!!!! I'm at my wit's end!
Can anyone even help me figure out how to get a more informative error message?

You can e-mail me directly at swong at rice.edu.

Thank you anybody!
-- Stephen Wong

[jclausius]

Stephen:

If the service description page is coming up and Ping() returns 1, then the server "seems" to be working correctly, but there could be something else amiss.

You could try to put the Vault Server in Debug Log mode, recycle IIS, and then try to re-log in with a Vault client or admin tool. After which, you can inspect the Log file. The log file should contain the start up messages, and then you should see the other web service calls made by the connection.

If all you see is the startup, then something is interferring with IIS passing control to the Vault web service. In this cases, you might try running aspnet_regiis.exe -i (found in %windir%\microsoft.net\framework\v1.1.4322\ ) to reset IIS w/ ASP.Net or perhaps something in Installing Vault Server on Windows 2003 Server may shed some light on the problem.

[jclausius]

Stephen:

One other thing comes to mind. You mentioned a web.config in wwwroot. If another application is using an HTTP Handler to manipulate the stream before being handed to the Vault server that may be causing the problems.

In a case like this, I'd recommend creating a completely new web site within IIS located in a different directory than %systemdrive%\inetpub\wwwroot. You could then install Vault onto this new site.

HTH

[swong]

How do you set the Vault server into Debug Log mode without logging into the Admin tool?

I already double-checked all the items in "Installing Vault Server on Windows 2003 Server" and everything had already been set. I forced them again anyway and rebooted. No effect.

I also already tried "aspnet_regiis.exe -i" several times but to no avail.

I will try the separate web site in IIS. I used to have Windows Sharepoint Services installed but I removed it before installing Vault. I have noticed that the Frontpage server extensions still say v. 6 instead of v. 5 like they should even though I told the sytem to remove the Frontpage server extensions and reinstalled FPSE 2002.

Thanks for you help!

[jclausius]

How do you set the Vault server into Debug Log mode without logging into the Admin tool?

Modify the vault.config file. Change the Xml element for logging from "Quiet" to "Debug". I should have covered that in the earlier post. Sorry about that.

I will try the separate web site in IIS. I used to have Windows Sharepoint Services installed but I removed it before installing Vault. I have noticed that the Frontpage server extensions still say v. 6 instead of v. 5 like they should even though I told the sytem to remove the Frontpage server extensions and reinstalled FPSE 2002.

One other thing you could try is to temporarily rename the web.config found in %systemdrive%\inetpub\wwwroot, and then try Vault. If things work as expected you know the cause of the problem.

[swong]

Jeff, you're a genius! Your idea of renaming web.config worked!

I renamed it, got Vault up, then slowly went back in and recreated web.config line by line until I found the offending line. So, after about a hundred reboots of IIS, I found that in the <httpModules> section, there was a line that was commented out in the original web.config:

<add name="Session" type="System.Web.SessionState.SessionStateModule"/>

Uncommenting this line made Vault work.

Prior to this line in the <httpModules> section, there was a <clear/> tag folllowed by some other name definitions. Simply removing everything from the <httpModules> section worked, but I found a web page that referenced web.config files made by Sharepoint: http://www.sharepointu.com/forums/WSS_v ... 454/tm.htm that said all that needed to be done to make an ASP.NET application work was to uncomment the above line.

I don't really understand what this SessionStateModule really does however and how it affects Vault. Could you explain that for us please, so that I can better understand issues that may come up in the future?

Thanks!

[jclausius]

Stephen:

In a nutshell, Sharepoint is acting naughty. Here's what is happening:

1) When Sharepoint is installed, it says, "Hey, I'm the top dog here. I don't like the default settings that IIS / ASP.Net ship with. Since, I'm the boss, here is how things are going to work."

2) Now, having a web.config in wwwroot will override all normal default settings found in ASP.Net. Thus when the Session module is removed from any web app found under the web site where Sharepoint is installed.

3) Vault relies on session state to store things like authentication tokens and other users settings to operate correctly.


Now, in my original post, I had asked if you could create another web site. That solution would also have worked, as it would have created a brand new web site ( without a web.config in the new root ). This would have caused the applications to use the standard ASP.Net configuration.

HTH