Brother Printers. No they can’t.


of course you’ve already read about the recent problems with the Logitech Webcam Drivers (if not see Nick Hodges’ blog). Well, I think this is the right moment to report about another issue, this time regarding Brother Printer Drivers and my long-term investigations about closing a handle leak.

Let’s start with the problem: While doing some quality tests on one of our own applications I’ve discovered that after each print job the handle count increases by 1.

First of all I thought of the component being used as the source of the problem. In this case it’s THtmlView. As I am also one of it’s developers since the very early D2009 days I rewrote the whole printer implementation to see if this fixes anything. This already took some time…

Result: Nope.

So, I thought of – let it sound diplomatic – a small problem in the VCL printing solution. I rechecked each and every QC entry for Printers.pas.

Result: No corresponding entry.

We wouldn’t be developers if we don’t know about other ways to find the real source.

I came up with a small example code in a plain D2009 project:

procedure TestPrinter;
  i: Integer;
  for i := 0 to 100 do
    Printer.EndDoc; // or .Abort

To save paper I always switch to offline mode before doing such tests. Be sure to do the same 😉

The example: Calling this procedure in an empty project leads to +100 handles leaking after each call. In other words, after using it 10 times the application would suffer from 1000 more handles being used.

Can this be true? Having done a quick compare between D7, D2006 and D2009 I must state that the D2009 Printers.pas is far superior against the older releases. Most (if not all) QCs are resolved for it. Correct titles, handling of device properties and so one. Just as a side note.

I thought of it being related to some kind of RTL/VCL changes. Retested for D7, D2006.

Result: Always failing.

So I’ve gone ahead: Test other operating system. Having real test machines and VMs has always been useful.

Result: Also failing.

Last step to check: Is the problem really related to the Delphi application?

Result: … drum roll … No!

I started a plain Notepad, printed a page. Nothing useful as handles increases with the first job being printed on every application due to the printer driver being attached, right?

But the Notepad suffers from the same problems. Manually printed one page after another, about 20 times. Each print job increases Notepad’s handle count by 1.

That’s the right direction, isn’t it? Ok, let’s shorten up the technical part of it:

Result: The brother printer driver dll attached to the process leaks. Using several SysInternals’ tools I am able to prove this.

Using handle.exe from the suite I saw

Section \Sessions1BaseNamedObjects17e25cPORT

being attached to the process in proportional relation to the print jobs (the numbers of course change for every new application process). The latest drivers (localized and unlocalized) from Brother did not solve the problem.

So I used some of the shipped default drivers from Vista, e.g. HP DeskJet 450. Of course, no problem with increasing handles. For none of the systems and none of the applications tested.

I checked the version of the brother drivers. It’s (release 3.23) for MFC laser printers. They are used for a wide series of printers, like the 7010, 7020, 7025, 7220, 7225N, 7420 and 7820N. Probably also in other series.

The file which has this leak is called: BROMF04B.DLL

So the drivers have a problem with an unreleased handle or better a not reused kernel object (event, semaphore, mutex).

I’ve mailed this to the european customer support of Brother International. No reply after a week.

Yesterday, I had a ~70 minutes call to Brother USA in Tennessee. I wanted to let them know of the problem. Here my real odyssey after months of debugging began: I was told that my printer is not manufactured for the United States but for European market. I was calling from Europe, as I told the support tech before (!) so I was not wondering about this information.

She said the drivers are localized and therefore different. I checked this before, of course. They were the same. Recently as I am working on english systems I am solely using unlocalized drivers. Imho, they are just a wast of space…

I tried to tell about the problems, had been forwarded three times. Waited for minutes to let her check back for other technicians to talk to. No one was understanding or even interested in this issue. Just speaking of: Is the device printing or not. I told about the leak and the tests and the file. The dialogue: Is the file missing. – Me: No. – So you have a problem with printing. – Me: Well, yes, indirectly. – So your device is not printing. – Me: No, it also happens without the printer being attached when using the offline mode (and so on).

Finally I was told to send my report to Brother International Corp. in Bridgewater, New Jersey. By mail. No, not the fast one. Nobody was able to give me the email address of a technician.

What should I do now? I wanted to help them fix their products and already invested my time and my money.

This has been an issue I’ve been investigation since a few months now. Since last week I know of the brother printer driver being the source of it. I can only open a support case in Europe – receiving meaningless default answers. Kudos!

Imagine the following: Our application is designed for 24/7 usage. The handles increases day by day. Reaching 50.000 to 400.000 after a few months and boom, your application or OS crashes. This can result in problems from unpredictable behaviour of the application up to a total crash with potential data loss.

Shouldn’t Brother care about?

Just my 2c.

Best regards,


P.S.: If anybody has better possibilities to reach the Software Development Team @ Brother International Corp. please drop a mail or leave a comment 🙂


OpenSSL v0.9.8j for Indy


yesterday a new version of the OpenSSL libraries has been published. I have just created precompiled DLLs for use with Indy again which are now available.

You can download the libraries from Fulgan’s Mirror.