PRB: SQLMail Is Not Supported When You Run the Server in Fiber Mode

This article was previously published under Q308604
This article has been archived. It is offered "as is" and will no longer be updated.
SQLMail may stop responding (hang) when the server that you are using is run in Fiber mode. Fiber mode is when you set the lightweight pooling option ON by using the sp_configure stored procedure.

When SQLMail stops responding:
  • You cannot invoke any new SQLMail functions such as:

    • xp_sendmail
    • xp_readmail
    • xp_findnextmsg
    • xp_deletemail


  • Existing SQLMail connections do not work.
From a SQL Server perspective, generally all new non-SQLMail connections and existing non-SQLMail connections function normally. However, there may be rare situations in which SQL Server may also become unresponsive.
Both MAPI and SQLMail make use of "critical section" synchronization objects in their implementation. The implementation details of both MAPI and SQLMail may encounter situations where the initial thread is scheduled out after entering a critical section and later may get rescheduled to a different thread. The rescheduling to a different thread causes the program to stop responding. According to the Microsoft Windows 32 documentation, a thread that enters the critical section must be the same one to exit the critical section or the critical section is not released. If the critical section is not released, the program may stop responding. Due to these architectural limitations of SQLMail and MAPI, Microsoft does not recommend or support SQLMail when the server is running in Fiber mode.

For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
303287 BUG: DTC Transactions Fail When SQL Runs in Lightweight Pooling

Article ID: 308604 - Last Review: 01/16/2015 23:34:56 - Revision: 3.1

  • Microsoft SQL Server 2000 Standard Edition
  • kbnosurvey kbarchive kbprb KB308604