Slow File Saves Using Structured Storage Commits with Large Docs

This article has been archived. It is offered "as is" and will no longer be updated.
As the structured storage file increases in size, it takes more time to save than expected.

From a developer's point of view, this is what would be occuring in his or her code:
Create root storage in  STGM_TRANSACTED mode.Create a single substorage on the root in STGM_DIRECT mode.Loop  for a lot of iterations, say 3000.Create a new stream.Write some data, 150 KB for instance, to stream.Commit root, say every 200 iterations, though loop.Release stream.Goto start of loop.					
The commit on the root will become very slow as the file gets larger. After 2,800 150-KB streams have been written, the commit on the root for the last 200 streams takes about 16 minutes. During the commit operation, 100 percent of the CPU is being consumed and no disk activity occurs. It is only just before the commit returns that there will be large amounts of disk activity.
To resolve this problem, obtain the latest service pack for Windows NT 4.0 or the individual software update. For information on obtaining the latest service pack, please go to:
For information on obtaining the individual software update, contact Microsoft Product Support Services. For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web:
Microsoft has confirmed that this is a problem in Windows NT 4.0. This problem was first corrected in Windows NT version 4.0 Service Pack 5.
More information
Two hardcoded values used for this function were increased:
Define MaxPages 24 to 128
Define MaxPagesScratch 3 to 16

Article ID: 221124 - Last Review: 01/07/2015 09:35:14 - Revision: 4.0

  • kbnosurvey kbarchive kbhotfixserver kbqfe kbbug kbfix KB221124