Arvid’s Blog @ digivendo

Hi,

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;
var
i: Integer;
begin
for i := 0 to 100 do
begin
Printer.BeginDoc;
Printer.EndDoc; // or .Abort
end;
end;

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 \\Sessions\1\BaseNamedObjects\17e25cPORT

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 0.3.0.0 (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,

Arvid

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

Arvid Delphi Brother, Bug, Delphi, Handle, Leak, Logitech

Hello,

you probably know of the tutorials Nathanial Woolls of InstallationExcellence has published some time ago regarding the Vista Issues under Delphi Versions below D2007 (available here and here).

As I’ve just checked Andreas Hausladen’s QC report #58939 which deals with the fact that Applications created by Delphi 2007 have no Taskbar Button when started minimized using the ShellLink, I’ve discovered that the same applies for anything below D2007 using the above mentioned Vista tweaks of InstallationExcellence:

You’ll receive a minimized TApplication Window on the desktop with no Taskbar Button assigned to it.

After stepping through the VCL sources of D2006 I saw that the problematic part is in TApplication.Run where CmdShow = SW_SHOWMINNOACTIVE is checked and a few lines below “Minimize;” is called.

Together with Nathanial’s fix this won’t do. To circumvent it you will have to make a small addition to his fix in order to have a correct behaviour together with minimized ShellLinks:

ShowWindow(Application.Handle, SW_HIDE);
SetWindowLong(Application.Handle, GWL_EXSTYLE,
GetWindowLong(Application.Handle, GWL_EXSTYLE) and not
WS_EX_APPWINDOW or WS_EX_TOOLWINDOW);
ShowWindow(Application.Handle, SW_SHOW);

// add the following lines:
if (CmdShow = SW_SHOWMINNOACTIVE) then
Application.ShowMainForm := False;

Assuming you are using Nathanial’s fix correctly in the MainForm’s OnCreate the given lines ensure that the MainForm is already hidden before Application.Run has been called.

Arvid Delphi Bug, Fix

Hi,

for all of you who discovered some resizing and or drawing bugs with Delphi under x64 Operating Systems have a look at the post in Jordan Russell’s Forum.

The bug is related to a stack overflow condition in the Windows kernel arising when a WH_CALLWNDPROC hook is installed. Regarding to Jordan’s post this reduces the time SendMessage() can be called recursively.

The good news: Andreas Hausladen has also published a fix for this issue.

This fixes not only problems with Jordan’s Tb2k but also Robert Lee’s SpTBXLib under x64 Vista as posted in jrsoftware.toolbar2000.thirdparty newsgroup on July, 23rd 2008.

Using the patch is as easy as adding a single unit to your project’s .dpr file:

uses
ControlResizeBugFix;

Thanks Andreas for providing the fix and Robert Lee for pointing to it!

Arvid Delphi Bug, Fix