2

An applications starts multiple other applications (components) by (D)COM+. There seems however to be some sort of maximum that can be started on the server.

The master application is written in c#, the others components in Visual Objects, 32 bit.

I've seen this problem on multiple Windows versions, including Win 7 prof and 2008 server versions.

Depending on how the component is started I get a class does not exist or

Retrieving the COM class factory for component with CLSID {50495402-21B7-11D4-A041-00A024E1D270} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).

In the latter case the system eventlog states:

Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"
System
Provider Name="Win32k"
EventID Qualifiers="32768" : 243 
Level : 3 
Task  : 0 
Keywords : 0x80000000000000
EventRecordID : 36855
Channel : System
computer : W151.piramide.lan

EventData
 Data 
 Binary : 000000000100000000000000F3000080000000000000000000000000000000000000000000000000

I'm stuck for instance at my machine with arround 48-50 components.

In an earlier version of the master application (written in Visual Objects) I can connect 273 components.

Any hints/ideas?

Toby Allen
  • 10,997
  • 11
  • 73
  • 124
OChristiaanse
  • 41
  • 4
  • 1
    There is no theoretical limit to the number of COM objects that you can run, although - naturally - if you try hard enough, you will eventually run out of some resource. You have to look at the server object/program, or how you are using it, to see why it fails (try adding some logging to it?). That's what CO_E_SERVER_EXEC_FAILURE means: "DCOM started the process to service an object request, but the process did not respond to the request". There is nowhere nearly enough information in the question to hazard a guess, other than "the problem is almost certainly not caused by COM" – Euro Micelli Jun 27 '14 at 03:38
  • Any hints on what resources that could be? I'm certain it isn't general memory. – OChristiaanse Jun 27 '14 at 07:22
  • 1
    You could start with a search for the event information. A quick search for 'eventid 32768 243' returns a bunch of matches with phrase "a desktop heap allocation failed". Sounds like a good hint. Research that phrase and look at your program to see what could be consuming so much desktop heap. – Euro Micelli Jun 27 '14 at 10:38
  • Your components create too many windows, something called "Visual Objects" would be a hint. Surely unseen by anybody since they run in session 0. Which by default uses a small desktop heap since services are not supposed to create many windows. You need to increase the heap size, well [covered here](http://blogs.msdn.com/b/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx). – Hans Passant Jun 28 '14 at 10:57
  • @Hans Passant "Visual Objects" is a programming language by CA, GrafxSoft, see [link](http://www.cavo.com). I'll check out the possibility to increase the desktop heap and look into what could possibly be the difference between the two scenario's. – OChristiaanse Jun 30 '14 at 05:48
  • The problem was indeed the desktop heap limitations. see also http://stackoverflow.com/questions/17472389/how-to-increase-the-maximum-number-of-child-processes-that-can-be-spawned-by-a-w – OChristiaanse Aug 06 '14 at 10:04
  • The problem was indeed the desktop heap limitations. see also [link](http://stackoverflow.com/a/17472390/2389652) By increasing the desktop heap size, the number of components that could be started/connected also increased. – OChristiaanse Feb 17 '15 at 16:57

0 Answers0