COM+ Error On 2000 server

[Markahipp]

I am currently running an C++ application on a Windows 2000 server that simply recives messages through the Mailslot and writes the recieved messages to a access database via a sequal statment using ADO.
The whole process works about 1000 times and then it will generate the following error in the Event Viewer:

Event Type: Error
Event Source: COM+
Event Category: Executive
Event ID: 4199
Date: 10/17/2001
Time: 7:36:16 AM
User: N/A
Description:
The COM+ Services DLL (comsvcs.dll) was unable to load because allocation of thread local storage failed.

Process Name: Server Status Window.exe
Error Code = 0x80070008 : Not enough storage is available to process this command.
COM+ Services Internals Information:
File: .\comsvcs.cpp, Line: 289

I can clear this problem up by simply stopping the application and restarting it.

Here is the c++ function:

#include <stdio.h>
#include <string.h>

#import &quot;C:\Program Files\Common Files\System\ADO\msado15.dll&quot; no_namespace rename(&quot;EOF&quot;, &quot;EndOfFile&quot // requires at least version 2.61.7326.0

void main (void)
{

CoInitialize(NULL);
try
{

_ConnectionPtr Conn(&quot;ADODB.Connection&quot;
Conn->Open(&quot;Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\inetpub\\logonmsg.mdb;&quot;,&quot;&quot;,&quot;&quot;,adConnectUnspecified);

sprintf(sqlstat, &quot;INSERT into Messages (Dates,Times,Type,UserID,Source,Computer,Description) VALUES ( %s,'%s','%s','%s','%s','%s','%s')&quot;, da, tim, typ, usid, org, comp, des);

Conn->Execute (sqlstat, NULL, adCmdText);
Conn->Close();

}
catch(_com_error &e)
{
printf(&quot;Description = '%s'\n&quot;, (char*) e.Description());
}
::CoUninitialize();
}

And help would be appreciated!

Thanks!
Mark

 

[Mendonca]

I have exactly the same problem.
Do you already know how to fix it ?

Thanks!
Jose Mendonca

 

[Markahipp]

Jose,
I have been unsuccessful in fixing this problem. If you or anyone else finds anything I would really appreciate knowing how to fix this.

Thanks,
Mark

 

[DASMAN]

Hi,
Im'not expert on C, but it seems to be a problem with somthing that you have not released.
Maybe you have to assign Conn to nil to realease the com instance of the com connection object.

Das

 

[Guest_imported]

Maybe this information might help.


Microsoft Platform SDK, November 2001 Edition

Using the SDK Headers
This version of the Microsoft® Platform SDK enables you to create applications that run on Microsoft Windows® 95, Microsoft Windows NT® 4.0, Windows® 98, Windows Millennium Edition (Windows Me), Windows 2000, Windows XP, and Windows .NET Server. You can also create 64-bit applications. The header files use data types that allow you to build both 32- and 64-bit versions of your application from a single source code base. For more information, see Getting Ready for 64-bit Windows.

Microsoft® Visual C++® includes content from the edition of the Platform SDK that was current at the time Visual C++ was released. Therefore, if you install the latest Platform SDK, you may end up with multiple versions of the same header files on your computer. To ensure that you are using the latest version of the SDK header files, follow the directions included in Installing the Platform SDK with Visual Studio. Otherwise, you will receive the following error when compiling code that uses features that were introduced after Visual C++ was released: error C2065: undeclared identifier.

Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows. To compile an application that uses these functions, you must define the appropriate macros. Otherwise, you will receive the C2065 error message. The following table indicates the macros you must define to target each system.

Minimum System Required Macros to Define
Windows NT 4.0 _WIN32_WINNT>=0x0400
Windows 98 _WIN32_WINDOWS>=0x0410
Windows 2000 _WIN32_WINNT>=0x0500
Windows Me _WIN32_WINDOWS=0x0490
Windows XP and
Windows .NET Server _WIN32_WINNT>=0x0501
Internet Explorer 3.0, 3.01, 3.02 _WIN32_IE>=0x0300
Internet Explorer 4.0 _WIN32_IE>=0x0400
Internet Explorer 4.01 _WIN32_IE>=0x0401
Internet Explorer 5.0, 5.0a, 5.0b _WIN32_IE>=0x0500
Internet Explorer 5.01, 5.5 _WIN32_IE>=0x0501
Internet Explorer 6.0 _WIN32_IE>=0x0600


For example, to use the features specifically marked for Windows 2000 in the header files, you need to explicitly define _WIN32_WINNT as 0x0500 or greater. You can define the symbols using the #define statement in each source file, or by specifying the /D_WIN32_WINNT=0x0500 compiler option supported by Visual C++.

Visual C++ 6.0: To specify compiler options, go to the Projects menu and click Settings, then select the C/C++ tab.

Visual C++ 7.0: To specify compiler options, go to the Projects menu and click Properties.

The macros in Win32.mak can help you define the correct macros. The value of _WIN32_WINNT depends on the platform you choose to target. For more information, see Building Applications Using Win32.mak.

 

[Guest_imported]

try use the following statement

CoInitializeEx(NULL,COINIT_MULTITHREADED);

to replace

Initialize(NULL);

 

[Guest_imported]

No solution yet, but I thought I'd throw in that I'm having the same error msg with an app written in VB6. It's a pretty large app and I didn't write it, so I don't know many more details. It doesn't use any significant APIs or other low-level stuff, so I'm pretty sure it's the VB code causing the error. There are quite a few ADO calls, so I would assume that's the root of my problem also.

bgh0055@yahoo.com

 

[DjAttitude]

Ok, a Solution for C++ has been found, but still cant find why VB is moaing oh well..

C++ users

Goto Project Setting -> C/C++ tab -> Preprocessor catergory

Add '_WIN32_DCOM' to the preprocessor defintions, (you may need the , seperator)

And also goto the General Category in the same tab. and add, yet again add '_WIN32_DCOM' to the preprocessor defintions.

Do a Clean Build, and hopefully, all should be well.

Any problems, let me know.

 

[platinumdragon]

DjAttitude - Couldn't get CoInitializeEx(...) to compile in C++. Your _WIN32_DCOM solution worked. Thanks!

 

[Chizl]

platinumdragon,

Did _WIN32_DCOM fixed the:
The COM+ Services DLL (comsvcs.dll) was unable to load because allocation of thread local storage failed.

error? I'm also getting this error in C++ running on our clustered environment. I'm using ADO exacly like Markahipp is.

If I use
CoInitializeEx(NULL,COINIT_MULTITHREADED);
and I'm not using it in a multithreaded environment, will it cause an issue?

 

[Chizl]

Looks like, we are not the only one's having the issue..

http://www.cisco.com/warp/public/788/AVVID/unity_system_crash.html#cscdw68215

 

[Guest_imported]

hi

you can speed ADO up a little by changing

Conn->Execute(sql, NULL, adCmdText)

to

Conn->Execute(sql, NULL, (adCmdText | adExecuteNoRecords))

this might help because there will be less allocation of resources at runtime.

also you could try updating to MDAC 2.7, and using _bstr_t or CComBSTR to see if the allocation error is in sprintf

 

[Guest_imported]

I am also getting the same log event in a VB6 app using Jet. Does anyone know of a VB6 workaround? Thanks.

-Mike

 

[SemperFiDownUnda]

Ummm It appears to me that you MAY have to destroy your Connection.

Closing a ADODB connection does NOT destroy it. So I imagine you are leaking ADO Connections all over the place that are not attatched to any database.

Hope this helps

 

[sammoman]

I've got an NT Service I've written logging events to a SQL table using ADO in more or less the exact manner as Markahipp above, except that I'm using the SQLOLEDB driver.

I'm also getting the same errors...

I'm already using _WIN32_DCOM as suggested and it's still happening (although less frequently). I'm not using CoInitializeEx(, MTh) since I'm not multithreading.

My Connection object is wrapped up in the ConnectionPtr object and is going totally out of scope and therefore (I'd assume) is being totally destroyed, since that also calls Release().

Any ideas or suggestions?

S

 

[SemperFiDownUnda]

Always explicitly release your COM objects. A pointer going out of scope does not destroy what the pointer was pointing to.

 

[Guest_imported]

Is anyone still seeing this on Win2K Server with *SP3*? I noticed there are a gazillion hot fixes for COM+ since SP2 but I have not yet applied SP3 to our production servers. I'm hoping beyond hope that SP3 fixes the problem.

 

[SemperFiDownUnda]

I'm still on SP2 but I applied at COM+ update to fix a few things. On thing is if you have public not createable objects then Component Services will not create a proper MSI for client machines.

 

[Guest_imported]

Win2K Server with *SP3*? does not remedy this problem.

 

[Guest_imported]

Releasing ( conn.Release() ) the connection pointer does not solve the problem. I have read that there is a small leak connection object's open() member function. One solution would be to limit the number of calls to this function, unfortunately for me this is not an option.