Microsoft Visual SourceSafe Best Practices

Microsoft Corporation

March 1999

Summary: Outlines recommended practices to help prevent data corruption in Microsoft® Visual SourceSafe™. (12 printed pages) Includes a discussion on the data repair Analyze tool that ships with the product. Covers:

Introduction
General Database Recommendations
How Visual SourceSafe Tracks Files
Finding and Repairing Data Corruption
Backup and Restore
Article Reference

These topics are not intended to be the sole reference for Visual SourceSafe. Product documentation, the Help files, and the Microsoft Knowledge Base are also good resources. The Knowledge Base is the most up-to-date source of breaking news and information on Microsoft products.

Introduction

Under normal operation in a stable environment, Visual SourceSafe provides excellent storage and security for your current source data and past revisions. As with any database product, however, under typically imperfect conditions it is possible for data corruption to occur. This article outlines recommended practices to help avoid corruption problems. Although all the practices will help minimize the impact of corruption, one of the most valuable is using a data repair utility called Analyze. The Analyze tool ships with the Visual SourceSafe product. It checks for and repairs many common data write errors. Run Analyze on your Visual SourceSafe database in concert with your regular tape backup schedule to ensure the stability and security of your source data.

General Database Recommendations

Database Size

Under normal usage, your Visual SourceSafe database should not exceed 3-5 GB in size. In determining an appropriate size, consider the amount of free space on the server, the relationship among the projects being stored, the amount of file history you need quickly accessible, and user tolerance for reduced performance. Although Visual SourceSafe does not have any built-in size limitation, on very large databases it takes longer to perform normal operations and maintenance tasks, such as running Analyze. Visual SourceSafe does not limit the number of databases that can be put on a file server.

To reduce potential file size, keep projects that are not interrelated in separate databases. You can use the Archive and Restore utilities, included in Visual SourceSafe version 5.0 and later, to move projects to another database or to remove outdated history from a project.

Location

Although you can store Visual SourceSafe databases on any Microsoft Windows®-compatible file server (Windows NT, Novell, Banyan, and so on), database performance is best on Windows NT. Not only are network operations generally faster, but the server-based Windows environment allows you to run Analyze and other highly intensive file I/O operations directly on the server, often dramatically decreasing execution time.

Analyze Frequency

Run the Analyze tool shipped with Visual SourceSafe to detect and repair problems in the database structure. Running Analyze regularly, especially in high-use situations, allows you to discover small problems and fix them before they become worse. Run Analyze weekly or, at minimum, monthly as part of regular maintenance.

Tip   While running Analyze directly on your production database, you must lock out users. To minimize the impact on users, restore your regular backup to another location and run Analyze on that copy. If you detect problems in the backup that need to be resolved, you can then lock out users from the production database while making any necessary fixes. If Analyze returns no errors, you do not need to interrupt user connections. This method also checks the validity of the backup strategy.

Create a physical list of all items in the database each time you run the Analyze utility. The physical list is useful in determining what logical file name is related to an error, based on the physical file name (for example, Abcaaaaa.a) for which the error is reported.

To create the physical list

For more detailed information on Analyze see the section "Finding and Repairing Data Corruption" later in this document.

Free Disk Space

Caution   Do not allow Visual SourceSafe or the Analyze tool to run out of disk space while running.

Running out of disk space in the middle of a complex operation can create serious database corruption. Visual SourceSafe does check for disk space, but due to performance concerns it does not check for space on every disk write operation. To avoid possible database corruption, make certain there is enough free space on the server that a complete copy of the database could be created during normal Analyze operations.

Sharing and Branching

Use the Sharing and Branching features of Visual SourceSafe with discretion. Avoid Sharing or Branching across top-level projects because it complicates the process of archiving the project and restoring it into another database. Also note that when you branch files and then delete them, the space is not recovered until all copies of the branched file are destroyed in the database.

Number of Users

The acceptable number of users varies, depending on the performance of the server and the network. Again, controlling the size of the database will improve performance and allow more users to access the database with reasonable performance. The number of full-access users you have determines the number of licenses that you need for Visual SourceSafe.

Server Rights

All users must have create, modify, change/edit, and delete privileges for files in the Data folder and its subfolders in the directory tree.

Each database has its own User and Rights management systems. You cannot interrelate these files.

Ss.ini Files

Users' Ss.ini files are limited in size to 64 KB and a maximum of 10 different machine-specific settings. Each time a user logs on from a different machine the Ss.ini saves the window positions and other machine-specific information. If you are experiencing unusual, user-specific problems try deleting unnecessary entries in the user's Ss.ini file.

Working Folders

To maintain file integrity, make certain that all users have their own working folders for all projects. When multiple users share a working folder, a file checked out by one user may be modified by anyone with access to that folder. Maintaining separate working folders ensures that users only modify files they have checked out themselves.

System Clocks

Synchronize the dates and system clocks for all Visual SourceSafe client machines with the Visual SourceSafe server. This prevents check-in and check-out operations from appearing to happen out of sequence and affects any labels that are applied. Synchronizing dates and system clocks is particularly important when users from different time zones access the same database.

You can set up a Windows NT Server to act as a Domain Time Source server for users to synchronize their local date and time with the network. For additional information, see the Knowledge Base article "How to Set Up and Synchronize with Domain Time Source Servers (search on article ID Q131715).

New Databases

Avoid creating a new database by copying an existing one. This method can potentially cause problems because the globally unique indentifier (GUID) in the Um.dat will be the same for both databases. For details on how to create a new database, see Knowledge Base article Q123467, "How to Create a New Database in SourceSafe."

Moving Database or Visual SourceSafe Installations

To move a Visual SourceSafe installation, copy the entire VSS folder and all of its subfolders to the new location. However, do not use XCOPY to do this, due to the fact that it does not copy some zero-byte files. Use Windows Explorer to copy the folder(s). After you have copied the installation, the Visual SourceSafe clients need to change the #include statement in their local Srcsafe.ini to reflect the new location. No other modifications are necessary. To move just the database itself, perform the same operation on the Data folder and then modify the DATA_PATH line of the server Srcsafe.ini instead of the client Srcsafe.ini. When specifying the DATA_PATH, use the UNC method (i.e., \\SERVER\SHARE). For additional details, see Knowledge Base article Q176909, "HOWTO: Move a VSS Database or Project to New Location."

Integrated Environments

When using Visual SourceSafe through the integration in the development environments (Microsoft Visual Basic®, Microsoft Visual C++®, Microsoft Access, Microsoft FrontPage®, and so on) use the integrated component to perform Visual SourceSafe operations that can be done within that environment. For example, do not check out and check in files from both the Visual SourceSafe Explorer and integrated environments.

How Visual SourceSafe Tracks Files

Visual SourceSafe is a file-based version control system that is designed for use on multiple, industry-standard network servers. No special program needs to be executed on the server during normal usage. The core of a Visual SourceSafe database is the Data directory; it has a unique structure that is designed to allow maximum flexibility. A Visual SourceSafe Database consists of the following files and folders.

File/folder Description
SrcSafe.ini Visual SourceSafe database global settings and configuration information for all users.
Users.txt List of all users of the Visual SourceSafe database.
Data\Aaaaaaaa.cnt Physical name of last file added to the database.
Data\Crcs.dat CRC information used to speed up the get and check-out processes (Visual SourceSafe 6.0 format databases only).
Data\Names.dat Long file name information.
Data\Rights.dat User and project security information.
Data\Status.dat Visual SourceSafe Explorer cache file (used to speed up the display of the Visual SourceSafe Explorer).
Data\Um.dat User management information (names and passwords) and the database identifier (GUID).
Data\Version.dat Visual SourceSafe database version.
Data\A…Z (folders) Folders containing log files and data files.
Data\Backup (folder) Contains analyze log file (analyze.log), list of bad files (analyze.bad), and backups of files changed by analyze.
Data\Labels (folder) Label cache information used for label promotion (Visual SourceSafe 6.0 format databases only).
Data\Locks (folder) Used if Visual SourceSafe locking is enabled.
Data\Loggedin (folder) Contains user login files and an Admin.lck file, if the database is locked.
Users (folder) Contains Template.ini, which stores default values for the Ss.ini file for new users. The Users folder also contains a subfolder for each user. This subfolder contains an Ss.ini file defining user-specific settings. The Admin folder also contains Ssadmin.ini, which defines administrator settings.

Visual SourceSafe creates two files in the Data directory for every file and project that you add to Visual SourceSafe (with one exception described later in this section). These file pairs are distributed evenly across the A through Z subdirectories in the Data directory. The file without an extension (such as Qrbaaaaa) is the log file for the file type being stored. The log file contains internal information for Visual SourceSafe, such as who added the file, where it exists, and all the differences between the versions of the file. The file with an .a or .b extension (such as Qrbaaaaa.a) is the most recent version of the actual file, stored under a Visual SourceSafe physical name. Each time a file is checked in, the extension it is saved with alternates between .a and .b. When a user checks in a file, it is copied from their working directory to the Data directory and renamed to the physical name with either an .a or .b extension, whichever is not currently there. Visual SourceSafe then calculates the differences between the .a and .b files and stores it in the log file (the file without an extension). Once the log file is updated, the old copy of the data file is deleted. Under normal circumstances you should never have both .a and .b extensions for one physical file name.

When you share a file from another, no new file pair is created in the Visual SourceSafe database. Instead, Visual SourceSafe creates a reference in the original file's log, noting that the file also exists in another project.

Finding and Repairing Data Corruption

Use the Analyze tool, located in the Microsoft Win32® directory, to check for and correct corruption problems. You should run it as frequently as is practical—once a week is recommended, or at a minimum, once a month. Analyze checks all the files in the Visual SourceSafe Data directory for corruption or disconnected links and often repairs these with proper switch settings. Because Analyze is so thorough it can be slow to run.

For best performance, all users should log off Visual SourceSafe before you run Analyze.exe. If you choose to use the -F switch to repair problems, users are required to log off. However, if you want to run Analyze.exe without requiring users to log off, you need to use the -X switch.

Note   Due to the amount of file I/O required, you can dramatically improve performance by running Analyze local to the data (that is, on a Windows NT Server) rather than across the network.

Analyze has several switches you can use to tell it what to do when running. Do not try to use every switch at once. The more Analyze is required to do, the longer it takes to run.

When Analyze is run it executes in the following four passes.

Pass 1 Analyze checks every file in the Data directory to make sure that it is valid and is not corrupt.
Pass 2 Analyze checks the relationships between parents (projects) and children (files and projects).
Pass 3 Analyze checks the relationships between shared and branched files.
Pass 4 Analyze checks the files Um.dat, Rights.dat, and Names.dat and performs cleanup operations.

Analyze supports the following switches.

Switch Description
-B<folder> Specify the folder to use for backup.
-C Compress unused space. (This simply removes blank space and does not compress the log files.)
-D Delete unused files.
-DB Delete the Backup folder.

Caution   If you find corruption, create backup copies of logs before running Analyze with the -DB switch.

-F Automatically fix files with corruption. (Requires users to log off of database.)
-I- When the analysis is complete the program exits. (Useful if running in a batch script.)
-V1 Show only critical errors. (This is the default setting, if no -V switch is used.)
-V2 Show only significant errors.
-V3 Show all errors and inconsistencies.
-V4 Show errors, inconsistencies, and informational notes.
-X Do not attempt to lock the database when analyzing. (Recommended only when users must remain logged on while Analyze.exe runs; -X cannot be used with -F.)

Running Analyze in the following pattern provides good coverage.

Command line Description
Analyze -V2 <Database Path> The first pass should always be a nonfixing pass to locate any problems before trying to fix them.
Analyze -F -V2 <Database Path> If errors are reported in the first pass, run again in fix mode to correct them.
Analyze -F -C -V2 <Database Path> Errors corrected by Analyze in the first fix mode pass can unmask other problems that could not be seen before. Run a second fixing pass and use the -C option this time, to remove any unused space in the log files.

Each time Analyze runs it places an Analyze.log file in the Backup folder along with a file called Analyze.bad. The Analyze.bad file contains a list of all files in which Analyze found problems. When Analyze fixes a file it first creates a copy of the file in the Backup folder, so that the repair can be undone if necessary. Each time Analyze runs it requires that the Backup folder be empty or not exist. If there is sufficient disk space, it is a good practice to rename the Backup folders, instead of deleting them. This history can prove very useful in troubleshooting corruption issues. The errors and messages reported by analyze are discussed at length in Knowledge Base article Q152807, "INFO: Error Messages from Analyze Tool of Visual SourceSafe."

Analyze can also re-create the Status.dat, Names.dat, and Rights.dat files. To do this, simply rename or delete the files you want rebuilt and run Analyze -F. Analyze re-creates the Names.dat file with the spaces in long file names appearing as underscores. You then need to rename the file using the Visual SourceSafe Explorer. The Rights.dat file is re-created, but as an empty structure; you need to readd the rights for each user.

Microsoft occasionally updates the Analyze tool to include more checking or to improve performance. For the latest version of Analyze please visit the Microsoft Visual SourceSafe Web site, located at http://msdn.microsoft.com/ssafe/default.asp.

Backup and Restore

When backing up your Visual SourceSafe database, be certain you are getting a full backup of the database. Although you can use incremental backups, avoid them due to the possibility that some of the files from the database may not be able to be restored. If users are logged on to Visual SourceSafe and actively using the product, the files they have open will not be backed up by most standard backup utilities. Several backup and copy utilities allow you to back up open files. You can use these utilities, however, if someone is actively updating a file in Visual SourceSafe when the file is backed up; it is possible that the backup will be corrupt.

Visual SourceSafe automatically closes any files opened by Visual SourceSafe or an integrated application after 15 minutes of inactivity. (This requires Service Pack 3 of Visual SourceSafe 5.0 or later.) The user still appears to be logged on to Visual SourceSafe and the files will be reopened when they start working again. The Rights.dat and Status.dat files remain open, however, anytime users are logged on, and will not be backed up. You can rebuild these if needed using the Analyze utility. Each time the administrator modifies the rights by project information for a Visual SourceSafe database, Visual SourceSafe copies the Rights.dat file to a Rights.bak file. If necessary, you can rename the Rights.bak file during a restore process.

Note   Do not schedule Analyze to run at the same time as a backup of the database! If the backup program has files open that Analyze is trying to open, Analyze will shut down unexpectedly. Backups should be performed regularly, as part of the daily or weekly file maintenance and security process.

Caution   Never restore a complete backup of a database over an existing database. Visual SourceSafe maintains very complex links between files. Restoring a whole database backup over an existing database may confuse the links between files and cause incorrect versions of the files to be displayed in the database.

Article Reference

Administrator Reference

Q153285 FAQ: Will VSS 5.0 be able to read a VSS 6.0 database?

Q153925 FAQ: How Can I Find Out if My VSS Database Has Been Upgraded?

Q123471 HOWTO: Change the Data Directory Location

Q123472 HOWTO: Create a Unique SRCSAFE.INI File

Q131447 HOWTO: Use PHYSICAL Command to Find SourceSafe Database File

Q131448 HOWTO: Rebuild Corrupt RIGHTS.DAT File

Q138296 HOWTO: Use UNC Paths in Visual SourceSafe

Q138344 HOWTO: Set up a Shadow Dir in Visual SourceSafe Administrator

Q138475 HOWTO: Set Up Multiple Check Outs on a Project Basis

Q140537 HOWTO: Change the Data Directory Location for Integration Apps

Q150648 HOWTO: Resolve Files Checked Out by an Unavailable User

Q153500 HOWTO: Recover Disk Space in Visual SourceSafe

Q153873 HOWTO: Upgrade from SourceSafe 3.x to Visual SourceSafe 4.0

Q163797 HOWTO: Lock a SourceSafe Database

Q167290 HOWTO: Enable Visual SourceSafe Locking

Q175950 HOWTO: Change the Name of a Visual SourceSafe Database

Q176350 HOWTO: Open Visual SourceSafe to a Specific Database

Q176909 HOWTO: Move a VSS Database or Project to New Location

Q191289 HOWTO: Enable Event Error Logging for FrontPage 98 & SourceSafe

Q194826 HOWTO: Designate a Visual SourceSafe project as a Web Project

Q124525 INFO: How SourceSafe Locks Files in the DATA Directory

Q131022 INFO: Required Network Rights for the SourceSafe Directories

Q131450 INFO: Description of Files in the \SS\DATA Directory

Q133018 INFO: Visual SourceSafe Setup Registration Settings

Q135643 INFO: Basic Troubleshooting Converting from Delta to SourceSafe

Q138298 INFO: Visual SourceSafe System Capacities and Specifications

Q138343 INFO: New Features of Ddconv.exe in Visual SourceSafe

Q138479 INFO: Required Rights for SourceSafe Commands

Q139891 INFO: Visual SourceSafe Installation is Processor Specific

Q140316 INFO: All Variable Settings for Visual SourceSafe .INI File

Q148511 INFO: Default Content of the Srcsafe.ini File

Q149382 INFO: Setting Options You Can Modify in the Srcsafe.ini File

Q150645 INFO: Minor Inconsistencies in the Header Log for

Q152807 INFO: Error Messages from Analyze Tool of Visual SourceSafe

Q153872 INFO: DDConv Messages of Visual SourceSafe 4.0

Q156448 INFO: Some Files and Projects are Upper Case after Upgrade

Q157714 INFO: How SourceSafe Stores Log Files

Q157984 INFO: How SourceSafe Uses the DATA Directory

Q157985 INFO: Anyone Can Run SSARC.EXE if There Is No Admin Password

Q158702 INFO: How ANALYZE Passes Work

Q166259 INFO: Visual Interdev/Visual SourceSafe Integration Discussion

Q168634 INFO: When -d Switch of Analyze Deletes Files

Q170749 INFO: What Window Position Values in Some INI Variables Mean

Q171117 INFO: Increasing Page File Size May Help When Running Analyze

Q176553 INFO: Database Architecture Changes in 4.0, 4.0a, 5.0

Q176875 INFO: The Primary Functions of Ssarc.exe and Ssrestor.exe

Q186361 INFO: ERR "...Some links may not be restored"

Q193583 INFO: SSInt.exe Is Added to Visual SourceSafe 6.0

Q195024 INFO: Visual SourceSafe Creates a VSSVer.scc File

Q123476 PRB: SoureSafe "Error locking file" on Windows NT or Multi-User

Q129187 PRB: Files Truncated One Byte When Placed in SourceSafe

Q129188 PRB: PVCS Labels Are Not Converted with PVCS_SS.EXE

Q132421 PRB: Lock_Mode = lockfile Causes "Timeout Locking File" Error

Q133017 PRB: Branching Files in SourceSafe Causes Lost Disk Space

Q136401 PRB: Data Path Errors Starting SourceSafe

Q140593 PRB: Error "Names.dat may be corrupt" Appears

Q140594 PRB: Local SSADMIN Writes to Local (Not Server) Srcsafe.ini

Q142763 PRB: Path Problems on Client Installation of SourceSafe

Q145744 PRB: Client Installed from ReadOnly Server Won't Start

Q147837 PRB: "File not Found" Error Message During Check In

Q149378 PRB: File Not Found Error When You Add New Users

Q153501 PRB: "Error reading from file" When Logging into SourceSafe

Q153502 PRB: Unable to Open Project Error When Running Analyze

Q154486 PRB: Access Denied or File Locked When Log In to SourceSafe

Q154829 PRB: Rights by Project Are Not Always Inherited

Q155584 PRB: Files Missing or Not Displayed in GUI Interface

Q155631 PRB: Message "Error Writing to File" When Checking In File

Q155754 PRB: File Could Not Be Mapped to the SourceSafe Project

Q155888 PRB: Binary Files with Keyword Expansion Corrupted

Q156717 PRB: Rollback of Shared File Forces a Branch

Q157533 PRB: PVCS to SourceSafe Conversion Fails

Q159278 PRB: Can Log on to a Locked Visual SourceSafe Database

Q159283 PRB: ANALYZE Error "Unable To Create the Filemapping…"

Q160914 PRB: The Data File for () Was Not Found

Q161610 PRB: SSARC/SSRESTOR Change 4.0 Database to 4.0a/5.0 Format

Q162530 PRB: Invalid Handle on Client When Journal_Text Set to Bad Path

Q162531 PRB: Filenames Starting with Tilde Not Shown in Analyze -PSS

Q164263 PRB: "Incompatible Database Version" - ANALYZE vs. Explorer

Q167258 PRB: Analyze Leaves Files with .old Extension in Database

Q167263 PRB: <filename> is Already Open

Q172157 PRB: Do Not Use SourceSafe When Running SSARC or SSRESTO

Q172158 PRB: Setup Error: "You must have NT administrative privileges"

Q172376 PRB: Ddcerr.log Reports "DDCONV initializing" During Upgrade

Q173387 PRB: Restoring an Archive of an Entire Database

Q176732 PRB: Read-Only Files in Shadow Folder Are Not Updated

Q176878 PRB: Replacing Names.dat File Changes Long File Names

Q186402 PRB: User Admin Not Found

Q186420 PRB: Status.dat File Is too Large

Q186469 PRB: Rights from Parent Project not Inherited

Q189110 PRB: "File Already Open" Error w/VSS DB on Unix Server

Q193586 PRB: Error "Rights.Dat is already open" When Running Ddupd.exe

Q190881 SAMPLE: Analyze6.exe Utility for Visual SourceSafe

User-Specific Reference

Q154008 FAQ: What Microsoft Products Does VSS Integrate with?

Q123473 HOWTO: Increase Performance in SourceSafe

Q123474 HOWTO: Logon With a Name Other than the System Logon

Q127104 HOWTO: Set Up Multiple SourceSafe Databases

Q133377 HOWTO: Search for SourceSafe Articles Using KBKeywords

Q138147 HOWTO: Use the SourceSafe Explorer to Modify the Ss.ini File

Q153493 HOWTO: Perform a RollBack Without Losing History

Q158219 HOWTO: Use SourceSafe Over a RAS or ISDN Connection

Q167134 HOWTO: Open Visual SourceSafe to a Specific Project

Q180945 HOWTO: Disconnect a Project from Source Control

Q123470 INFO: How SourceSafe Selects a Viewer for a File

Q124530 INFO: Visual SourceSafe Project Oriented Version Control

Q130176 INFO: Project versus File Labeling in SourceSafe

Q131772 INFO: Setting Compare to Checksum Speeds GET Command

Q131773 INFO: Setting Compare to Time Increases Speed of GET Command

Q132892 INFO: SourceSafe Might Modify Some Files

Q136325 INFO: Three Types of Drag-and-Drop with Visual SourceSafe

Q138299 INFO: Legal Visual SourceSafe Naming Conventions

Q138385 INFO: Visual SourceSafe Shortcut Keys

Q147585 INFO: The Mssccprj.scc File and How Is It Used

Q148512 INFO: Description of the Properties/About Command Line Commands

Q150644 INFO: Quotes Required in Command Line for Names with Spaces

Q157527 INFO: New Visual SourceSafe Commands and Functionality

Q157717 INFO: VSS 5.0 Readme: Sec. 2, General Notes and Tips "

Q157718 INFO: VSS 5.0 Readme: Sec. 3, New Features in Visual SourceSafe"

Q157719 INFO: VSS 5.0 Readme: Sec. 4 & 5, VSS 4.0/VSS Home Page Users "

Q157720 INFO: VSS 5.0 Readme: Sec. 1, Software Installation Information"

Q157982 INFO: Understanding Promotions

Q158218 INFO: Support Options for Visual SourceSafe

Q158469 INFO: Time Difference in Checking Out vs. Getting File in SourceSafe

Q164941 INFO: Command Line Equivalent of "Build Tree" Option

Q185696 INFO: "Invalid DOS path :" when Adding Files

Q186320 INFO: Determining if a Web Project is Source Code Controlled

Q131092 PRB: Keyword Expansion Is Case Sensitive

Q150643 PRB: Setting Wrong System Date Causes Lost Project History

Q155437 PRB: "Invalid DOS Path" Error Message

Q160888 PRB: VSS Explorer Error: "This Is an Integration Only Project"

Q162113 PRB: Project Modification Not Reflected in Shadow Directory

Q167262 PRB: Unable to Open User Login File

Q173065 PRB: Problems After Branching Integrated DevStudio Projects

Q184354 PRB: Working Folder for Subproject Not Inherited from Parent

Q184357 PRB: Visual C++ Opens Project in Wrong VSS Database

Q186236 PRB: SCC Project Opens Very Slowly with Norton Anti Virus

THE INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.