This article was previously published under Q320407
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 356975 (SHILOH_BUGS)
The use of SQLMail extended procedures, such as xp_sendmail, can result in an access violation on SQL Server 2000 Service Pack 2 when SQL Server is running as a Microsoft Windows NT service.
To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
290211 INF: How To Obtain the Latest SQL Server 2000 Service Pack
NOTE: The following hotfix was created before the release of Microsoft SQL Server 2000 Service Pack 3.
The English version of this fix should have the following file attributes or later:
Version File name -------------------------- 8.00.603 Sqlmap70.dll
NOTE: Because of file dependencies, the most recent hotfix or feature that contains the files may also contain additional files.
This problem does not occur if SQL Server is run from a Microsoft Windows NT command prompt. For more information about how to run SQL Server from a Windows NT command prompt, see the section title "sqlservr Application" in the SQL Server documentation.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Microsoft SQL Server 2000 Service Pack 3.
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
If you see any access violation that is specific to the use of SQLMail extended procedures with SQL Server 2000 Service Pack 2, you must first apply the fix referenced in the "Resolution" section before you proceed with other troubleshooting steps.
When this access violation occurs, you will see a stack dump written to the SQL Server error log file and the connection that is running the SQLMail extended procedure closes. Subsequent executions of SQLMail procedures may appear to stop responding (hang) until SQL Server is restarted.
The information in the stack dump in the error log may vary depending on the version of Microsoft Outlook that is running on the computer where SQL Server is installed. The following stack dumps are examples that have been seen as part of this problem:
* Short Stack Dump* 62126156 Module(MSMAPI32+00026156) (HrGetOmiProvidersFlags+00003D0A)* Short Stack Dump* 77E857EA Module(KERNEL32+000057EA) (VerLanguageNameW+0000007E)* 77E85819 Module(KERNEL32+00005819) (VerLanguageNameW+000000AD)* 6213B73E Module(MSMAPI32+0003B73E) (MNLS_lstrcpyW+00001F03)* Short Stack Dump* 6212BAB6 Module(MSMAPI32+0002BAB6) (MAPIOpenFormMgr+00000F75)
After applying this fix, if you want to use SQLMail procedures while SQL Server is running from a Windows NT command prompt (not running as a Windows NT service), you must first add the following registry key value:
If the earlier registry key value is missing, use the following steps to create the registry key. You must create this key value if you are going to run SQL Server from the Windows NT command prompt and not as a Windows NT service.
Set the type of the value (RunningAsService) to REG_DWORD.
Set the value to 0 if SQL Server is not running as a Windows NT service.
You can use a value of 1 to indicate that SQL Server is running as a Windows NT service. If the registry key value does not exist, the default behavior is that SQL Server is assumed to be running as a Windows NT Service. Therefore, if SQL Server is running as a Windows NT Service, you do not have to create this registry key value.