Problem Starting More That 4 Bartend.exe As A Service Follow

Legacy Poster


We are using ActiveX to call Bartender from our C++ application. The program starts as a windows service and then starts bartend.exe via ActiveX call.
Each application starts only one copy of the bartend.exe. If we start up to four services (4 bartend.exe) then everything works as expected. But if we start more than 4 bartend.exe then all of them become CPU hungry (100%) and then crash with the following error:

Faulting application name: BarTend.exe, version: 9.40.2760.2652, time stamp: 0x4d7980a1
Faulting module name: unknown, version:, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00000000
Faulting process id: 0x1138
Faulting application start time: 0x01cd1642307e0d69
Faulting application path: C:\PROGRA~2\Seagull\BARTEN~1\BarTend.exe
Faulting module path: unknown

Running the same application as a normal program (not a service) does not produce this problem event with 10 bartend.exe up and running.

OS: Windows Server 2008 R2 Enterprise 64-bit.

Do you have any ideas how to fix this problem?


Ian Cummings
Comment actions Permalink

Update to the latest service release:

You will probably need to increase the non-interactive desktop heap memory that is available.

Desktop Heap

When BarTender is used in a "service context", it can be negatively impacted by a system setting known as "desktop heap". It is important to understand when this can occur, and how to correct the problem.

Desktop Heap
The "desktop heap" is a certain area of memory that is used to store information about windows, as well as objects that are used for drawing and printing. For more advanced technical information about what desktop heap is, see here:

In general, console (command line) applications do not use desktop heap memory. However, BarTender is a "Windows application", rather than a console application. When Commander controls bartend.exe processes one must understand that the BarTender application file is an integral part of the label designer, and it is impossible to print without creating several different windows, including the entire editor view. Those windows exist even when you cannot see them, and they use "desktop heap" memory.

Each instance of BarTender takes up desktop heap memory, and each format that is opened uses a bit more. (The exact numbers are difficult to measure, and vary by version, but in general as we add features in newer versions, we've been using a bit more desktop heap.)

The total amount of desktop heap memory depends on the "session" you are using. When you log in to your system, you have a visible "desktop" that belongs to your user name. That session has a block of heap memory, which is shared between applications in that session. If a different user logs in through Remote Desktop, they are using a separate desktop heap. The amount of desktop heap memory available to these sessions is known as the Interactive Desktop Heap.

Services run under a different session and have their own "desktop", even though you can't see it. Each service can have its own desktop, and therefore its own desktop heap. But there are many services on your system, so in order to limit the memory usage, Windows defaults the desktop heap size to a much lower value in this case. The amount of desktop heap memory available to these sessions is known as the Non-Interactive Desktop Heap.

Now, BarTender always uses desktop heap memory (every application that shows a user interface does). The interactive desktop heap is a number large enough to let you open thousands of windows, so we rarely see desktop heap as a problem in interactive sessions. But when running as a service, we can max out the default non-interactive desktop heap.

This can be difficult to diagnose. A common symptom is that when loading another format, BarTender may log an error like "Failed to create empty label format." However, this message is not guaranteed, sometimes BarTender will crash instead. It can also potentially print incorrectly, with missing fields. Depending on the credentials the service is running under, it may also be sharing a desktop heap with other services, and cause those services to malfunction in unpredictable ways.

If you are running BarTender under a service context, and you are encountering any type of reliability problem which does not occur when running BarTender either interactively or when running Commander as an application, this is a possible cause.

You can adjust the heap settings in the registry. However, the settings are embedded within a larger configuration string, and making a mistake is potentially dangerous. Therefore, we've created a tool to make this easier:


You will need to reboot for the setting to take effect (restarting the service is not enough).


I would suggest experimenting with a value of 1024 KB to start with, perhaps raising to 2048 KB if needed. Higher values can be specified if you have enough physical memory, and if you truly need it. Don't specify a value more that is required though.

Please sign in to leave a comment.