For details on the problem and its general cause, see the following post:
Problems with System.OutOfMemoryException At System.String.GetStringForStringBuilder in 32-Bit Managed Solutions

Managed code solutions that use classes from the System.Data or System.Xml name may encounter a System.OutOfMemoryException when working with large datasets, XML files, or repeated operations that involve hundreds of (xml) object serialization calls from standardized components.  The exception may cause the program to stop working or report an unexpected error to the user. 

When the exception occurs, the top of the call stack will typically appear as something similiar to the following:

System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at System.String.GetStringForStringBuilder(String value, Int32 startIndex, Int32 length, Int32 capacity)
at System.Text.StringBuilder.GetNewString(String currentString, Int32 requiredLength)
at System.Text.StringBuilder.Append(String value)
at System.IO.StringWriter.Write(String value)
at System.Xml.XmlTextEncoder.Write(String text)

The excact call stack may differ, and the problem can appear in many different products and different types of solutions, both on the client or on the server.

More Information

The problem is typically the result of a compound memory problem which results from limitations in the implementation of the StringBuilder class for .NET.  Even if you do not call the StringBuilder class yourself, many managed objects use it indirectly for serialization, and as show above, the System.Xml classes use it for constructing and reading XML data (a common task in .NET).

The problem occurs if the process runs low on contiguous virtual memory space. This condition can occur through the normal running of managed code under stress conditions or if you employ very large DataSets, XML files, or other large string blocks from the managed code space.  As you use StringBuilder objects, the memory buffer used for large strings is allocated directly from Virtual Memory, and is managed by the CLR on the Large Object Heap (LOH).  The CLR does not (by design) compact the LOH when doing garbage collection because of the negative performance impact it would incur. In addition, the LOH is not typically collected unless a full (generation 3) collection occurs, which is much less frequent than normal GC collections. As a result, extended use of the LOH can result in both the depletion and fragmentation of the process virtual memory space over time. Since StringBuilder uses the LOH for large strings, this problem extends to any class that might use StringBuilder for serialization, XML parsing, or data remoting.

In addition to the fragmentation issue, the StringBuilder class implements a simple algorithm for allocating more memory to expand a string buffer.  This system is designed for performance when dealling with small strings, but can result in poor memory use for very large strings (like you might see with a serialized DataSet), and tie up more memory than needed or expected. In addition, each time the buffer is expanded, another block of virtual memory is required and the original block may remain on the LOH because of low frequency of generation 3 collections.  These facts can compound the problem, depending on the exact situation involved.

Naturally, the problem is unlikely to occur with 64-bit applications since the virtual memory address range for a 64-bit Windows application is much much greater than 32-bit processes.   For comparison, a Windows 32-bit process has an address range up to 4GB, with typically 2GB accessible for allocations by the application. A Windows 64-bit process, on the other hand, has an address range up to 16TB, with 8TB (7TB on Itanium-based systems) accessible for allocations. 

Unfortunately, there is no single answer to problems involving this error.  While some solutions exist for certain cases (for example, DataSets can be remoted using binary representation instead of XML, or code that uses StringBuilder directly can intialize the buffer with a size large enough to hold the data being manipulated to cut down on duplication from "growing" strings), the problem is a limitation of the design of elements from both the StringBuilder class and the LOH itself.  Microsoft is investigating these problems to find solutions that can both manage the overall problem, while still keeping the fundamental performance of the original design.

OLE Link to Word 97-2003 File May Fail with OLE_E_CLASSDIFF Error on Open

You may encounter an OLE_E_CLASSDIFF (0x80040008) error on calls to OleRun or IOleObject::DoVerb when attempting to bind to a Word document saved as an OLE link.  This occurs when the following conditions are true:

• The document linked to is a Word 97-2003 document (*.doc).
• Word 2007 was used to create the link.
• The OLE link was made from an IDataObject pointer obtained from the clipbaord or a drag/drop operation.
• You get the error when attempting to bind to the linked document again when it is no longer running (i.e., it is not in the Running Object Table).

Cause

The problem can occur because when using the clipboard to obtain link data from Word 2007, the CLSID of the data return can be for a Word 2007 (*.docx) file type.  This occurs regardless of the actual file format type that the document is saved in.  The CLSID is persisted by the OLE link handler when the link is saved.  At some point later when you attempt to reopen the link, if the file specified by the link is not already running, OLE32 will attempt to start the object anew.  Before it does this, it compares the CLSID obtained from the binding to the moniker path to the CLSID saved from the OLE link. In this case, the moniker will return the CLSID {00020906-0000-0000-c000-000000000046} for a Word.Document.8 file type, but the CLSID saved in the link {F4754C9B-64F5-4B40-8AF4-679732AC0607} is for a Word.Document.12 type.  OLE considers these different object types and will return the OLE_E_CLASSDIFF error on binding.

Workaround

The OLE client can override the CLSID check made by OLE32 when binding, which can thereby avoid the problem.  To do this, check if the CLSID associated with the link is for the Word.Document.12 object type, and if it is, you can call IOleLink::BindToSource (before calling OleRun or IOleObject::DoVerb) and pass the OLELINKBIND_EVENIFCLASSDIFF flag.  This flag will tell OLE to ignore the CLSID differences and allow the CLSID specified by the moniker to open the link.  Since Word implements both objects the same in regards to links, this would work fine.

Status

This problem is a confirmed bug reported for Word 2007. 

Please see the following post for details:
Unable to Open Office Documents for Edit From SharePoint Behind Cisco CSS Load Balancer

When you build a Microsoft Office SharePoint (MOSS) server farm and configure it for load balancing, you may be unable to open Office documents for edit access (collaboration) if you are using a Cisco Content Server Switch (CSS) with Layer 5 content rules applied.  From the client, you may experience one of the following symptoms (depending on your version of the CSS software):

• The client application opening the document appears to hang, taking somewhere between six to ten minutes to open the file. When the file opens up it is read-only.
• The client application starts and loads the file right away, but the file opens read-only and the Workspaces Task Pane is unavailable.

Cause

As part of the process of opening documents for edit using URLs, Microsoft Office (2000-2007) client applications will request the server type and authoring protocol from the web server using the HTTP 1.1 OPTIONS verb as defined by RFC-2616 by the IETF.  The purpose of the call is to determine the capabilities of the web server hosting the document, and to detemine the web authoring protocol the server supplies (if any) which the client can use to edit the file. This behavior is described in KB838028 under the section "Microsoft Office Protocol Discovery."

Under its default configuration, the Cisco CSS software will not permit traffic using the OPTIONS verb to be handled by the web server(s), and will reject the call. Depending on your version of the CSS software, the error returned may be different and give you different behavior, but the end result is that you will be unable to open the files for editing from the client.

Resolution

To resolve the issue you can do one of the following:

• If you are running Cisco CSS version 7.50 or higher, you can enable an option to allow passthrough of WebDAV commands, which includes the OPTIONS verb. The command to enable the passthrough is:
  
  

  # http-method parse RFC2518-methods

• If you are running an older Cisco CSS version, you may be to resolve the issue by recofiguring the switch to avoid Layer 5 content rules. If the balancer is configured to apply a higher rule level Layer 5 (HTTP filtering), the code that disallows the call will not be encountered and the packet will be allowed to pass to the web server as expected. See your Cisco guide for help.

More Information

By design, the Cisco CSS software for Layer 5 content rules allows only the CONNECT, GET, HEAD, POST, and PUT verbs for HTTP 1.0/1.1.  Earlier versions of the switch software would simply reject these calls with a TCP FIN response, which could be treated by the client as a dropped connection.  The client could then get in a state of repeating the call to reestabilish the connection, which when repeated could result in a loop that lasts until the socket layer times out the call.  This could cause "hang like" appearance since the client is waiting on a server HTTP response that does not come.  Cisco altered the switch design to return a TCP RST instead, which prevents this "hang-like" loop by the client, but still blocks the call. Since Office is unable to communicate to the web server, web authoring is not available and the document will open read only (as returned by a standard HTTP GET request instead).

Starting around version 7.50 of the CSS software, Cisco added the ability for you to configure the list of verbs allowed by the CSS switch. Included in this update is a setting to allow all HTTP verbs defined for the WebDAV protocol as documented in RFC-2518.  While the OPTIONS verb is not specific to this protocol (and in fact, Office will use WEC and not WebDAV for authoring to SharePoint), the OPTIONS verb is central to the operation of the DAV protocol, and therefore must be enabled to use DAV.  So enabling the "RFC2518-methods" setting on the CSS will enable the OPTIONS verb, and will allow the client call to reach the web server as intended.

For information about the "RFC2518-methods" setting available in CSS 7.50 and higher, please see your CSS guide from Cisco.  Here is an online copy of the relevant section in the 8.20 documentation from Cisco: Configuring HTTP Method Parsing.

This behavior is "by design" according to the default settings of the Cisco CSS Layer 5 Content Rules.

Excel development has addressed these limitations in a comprehensive fix for Excel 2007, released as part of the the August 2008 Cumulative Update for Excel 2007 (see KB956836 ).

See the following post for full details:
SharePoint Document Library Date Time Columns May Be Incorrectly Changed for Office 2007 Documents if Opened and Saved by Office XP/2003

If you create a document library in Microsoft Office SharePoint Server (MOSS) with a custom column of a Date/Time data type, and you store Office 2007 (Open XML) documents in that library, if the files are opened, edited and then saved back to the SharePoint library using Office XP or Office 2003, the date/time value of the custom column property may mistakenly be changed to an incorrect time when the file is saved.  The problem is an incorrect conversion of the date time value from UTC to local time and back again, causing the time value of the property to be altered plus/minus some time increment equal to the time difference between your local time and the GMT time zone.  The problem pertains only to custom properties associated with a SharePoint document library, and only if the file is converted at runtime for Office XP/2003 (it does not occur if client is using Office 2007).

Cause

The problem is a confirmed bug in the Office 2007 Compatibility Pack converters for Word and Excel.  During the conversion process from Open XML format into the native formats used by Office XP/2003, a call is made to check if the file contains custom document properties associated with SharePoint lists or columns. If found, the properties are re-evaluated and thereby modified.  Due to a bug in this process, the properties are (re)saved in the native file in local file time instead of UTC.  When the native document is then opened, edited, and re-saved, Office XP/2003 believes the new time value is in UTC and thereby converts the local time back into Open XML format as if it was the UTC time.  When the file is saved back to SharePoint, the incorrect time is updated on the server and SharePoint displays the new (incorrect) time in the document library column. If the process is repeated, you may continue to gain/lose hours for that column.

Status

The problem is being investigated for a future fix in Office 2007 SP2 for the Compatibility Pack.

Steps to Reproduce

1.) On your MOSS server, log in with an account that has Designer or Full Permissions to the MOSS site.  Create a new document library. Name the library TestLib, and change the Document Template setting to Microsoft Office Word Document (this is the *.DOCX file type).

2.) Once TestLib is generated, view the (empty) library and choose Settings | Create Column.  Name the column TestTime, choose Date And Time as the column type, then choose Date & Time for the Date and Time Format type, and Today's Date for the default value. Press OK to create the custom column property.

3.) Go to a machine with Office 2007. In a web browser, navigate to TestLib on your MOSS site, then choose New | New Document.  This should prompt you if you would like to create a new file.  Choose Yes.

4.) After the file opens in Word 2007, modify the file is some way, then choose Save.  In the SaveAs dialog, you should see the TestLib location is already selected for you, so you just need to provide a file name and click Save.  The file should be saved.  Close the file.

5.) Switch back to the web browser and refresh your view.  You should see your file listed and the TestTime column with today's date and time.

6.) Go to a machine with Office 2003 and the Compatibility Pack installed.  In a web browser, navigate to TestLib on your MOSS site, then find the document you saved previously.  Click the link to open the file in Word 2003 (you can also choose the "Edit In Microsoft Word" dropdown option).

7.) The file will auto-convert and open in Word 2003.  Make any small change you like to the document and press Save. Close the file.

8.) Switch back to the web browser and refresh your view.  You will see the file was updated (as expected) and the TestTime column value has changed (assuming you are in a different time zone than GMT) which is not expected.  The time value was not modified by the user, so should have stayed the same. It did not.  The amount of time difference (+/- X hours) will depend on your local time zone.

See the following post for more information:
Field’s promoted from an InfoPath form template during publishing to a Microsoft Office SharePoint Server are created multiple times