Server Error 400 after applying hotfix for VSS

Oldman0215 · Post by **Oldman0215** » Wed May 17, 2006 7:18 am

We have VSS version 6.0d and SourceOffsite 3.01.
We applied Microsoft hotfix 837417 because we were unable to recursively fetch files by label.

This hotfix fixed the issue but it has appeared to have broken SourceOffsite. If I try to perform any get I get an operation failed error from the client. The server error log looks like this:

Begin Get File Operation: App.ico
Server Error 400

Is there anything I can do besides rolling back the hotfix?

lbauer · Post by **lbauer** » Wed May 17, 2006 8:35 am

We haven't tested SOS with Microsoft Hotfix 837417. We do know that some hotfixes have changed the VSS Automation Component so that it no longer works with SOS. The SOS Server uses the VSS Automation Component to communicate with VSS database.

Could you send us a copy of the Hotfix so that we can test it here? Zip up the files and email to linda at SourceGear.com.

How many SOS users is this affecting? Do you have many users using just the VSS client on the LAN?

Do you happen to know the version of the ssapi.dll file in the version of 6.0d that you were using previously? This file would have been in the VSS\Win32 directory. We aren't aware of problems with recursive label gets in VSS 6.0d.

Oldman0215 · Post by **Oldman0215** » Wed May 17, 2006 8:43 am

Sent hotfix.

Oldman0215 · Post by **Oldman0215** » Wed May 17, 2006 8:48 am

To answer your other questions.

All our users use SourceOffsite. Nobody uses the regular client unless they remote into the machine. We all work remotely from the VSS server.

Before the hotfix we were using SSAPI.dll Version 6.0.98.48.
After the hotfix the version is 6.0.40223.0

Oldman0215 · Post by **Oldman0215** » Wed May 17, 2006 9:32 am

I just wanted to correct something.
It appears our source offsite client is 3.5.3.
The server however lists 3.01.

lbauer · Post by **lbauer** » Wed May 17, 2006 2:28 pm

We were able to reproduce the problem with this hotfix. We can open an incident with Microsoft, but it may take some time for a resolution.

You could try using the VSS 6.0c Hotfix in the SOS Server machine. This
is a hotfix that Microsoft created specifically so that it would work with SourceOffsite.

You can download it from this link and replace the contents of the VSS\win32 with the contents of the archive.

http://download.sourcegear.com/files/vss_60c_hotfix.zip

Note: There are some differences between the way VSS 6.0d and VSS 6.0c work with SOS. For instance, with 6.0c, users will be able to see files in directories they don't have access to, although they can't checkout the files.

Grant.Wickman · Post by **Grant.Wickman** » Wed May 24, 2006 4:43 am

We are also having this problem after applying hotfix 892518

SourceSafe Version (before hotfix): 6.0d (build 9848)
SourceSafe Version (after hotfix): 6.0d (build 50118)
SOS Server version: 4.1.2
SOS Client version: 4.1.2

EXAMPLE OF ERROR
--------------------------------------------
24/05/2006 11:20:24 - 24/05/2006 11:20:24 - Server Exception (400): [C:\Program Files\SourceOffSite Server\temp\Ifs_source632840663460156250\WarrantDetailControl.ascx.resx] - OPERATION_FAILED
24/05/2006 11:20:24 - 1: Server Error: 400
--------------------------------------------

This has come at a bad time for us.

I am wary about applying the 6.0c hotfix since this may cause further problems with our database but will check with MS about the consequences of this.

This is obviously not an isolated problem so it would be better if you could recreate it on your site.

When you attempted to re-create the problem at sourcegear did you run the "ddupd [path to VSS database] - REDO" command to update the VSS database?

Did you try with SourceSafe logins that have access rights explicitly and no default access to the root "$"?

Did you try it with SOS clients that connect using encryption?

We will be happy to run a debug/verbose build on our servers if this helps you sort out the issue.

lbauer · Post by **lbauer** » Wed May 24, 2006 8:06 am

SourceSafe Version (after hotfix): 6.0d (build 50118)

This is the first report of a problem with this hotfix, so we haven't tested it. However a similar problem has been reported in two other recent SourceSafe Hotfixes. We are contacting Microsoft about this. We might be able to change something in SourceOffSite, but our past experience has been that if changes in the SourceSafe Automation component are incompatible with SourceOffSite, the fix must come from Microsoft. SourceOffSite communicates with the VSS database through the Automation Component.

I am wary about applying the 6.0c hotfix since this may cause further problems with our database but will check with MS about the consequences of this.

The 6.0c Hotfix was released in 2002 to solve a problem with concurrency crashes in SourceOffSite. It has been successfully used by thousands of our customers over the the last four years. It might be a good workaround until we get the other hotfix issues resolved. NOTE: This version of VSS only needs to be installed on the SOS Server machine itself. Most likely, VSS users will still be able to use the newer clients.

When you attempted to re-create the problem at sourcegear did you run the "ddupd [path to VSS database] - REDO" command to update the VSS database?

No, since this is a VSS command, and not available in SOS. Was there a problem running this command after using the SOS Server with the VSS 6.0c Hotfix version?

Did you try with SourceSafe logins that have access rights explicitly and no default access to the root "$"?

Yes. With 6.0c Hotfix, a user with no default access to root can see all projects and files, but can only act on the projects where they have access rights. That means they can see the contents of the tree, but cannot get, checkout, checkin, etc. where they have no access rights.

Did you try it with SOS clients that connect using encryption?

Yes, and users have been using the 6.0c Hotfix with and without encryption for the past 4 years.

Grant.Wickman · Post by **Grant.Wickman** » Wed May 24, 2006 11:44 am

After consultation with Microsoft our workaround was to back out of the hotfix and revert to build 6.0d (build 9848).

Our Source Offsite installation is working again.

SourceGear Support