Slow network printing to Magicolor 2300DL

Have had this problem since vista came out - and others have too (from my googling), but have not yet seen a working fix for it. We have a networked Magicolor 2300DL printer (ie, its connected directly to the network, not shared through a particular machine). When printing from a vista (or windows 7) machine, there is a delay of several minutes before the print starts. From XP its immediate. If I reinstall the driver, everything works properly until I reboot, then back to slow. I have tried various versions of the driver, and am definitely currently using the latest vista 32 driver from the konica minolta site. I had blamed vmware previously (but that was just because it was one of first things I installed, and it required a reboot, so printing slow after). Ideas like disabling the firewall or TCP/IP v6 make no difference. Other network functions are fine (I do a lot of copy over the network, mainly to XP machines, all works at expected speed).

Anybody knows how to sort this - much appreciated.

I'd expect the problem to be with the printer driver, based on the Vista/Win7 link and the fact that other transfer types occur at expected speeds.

How old is the newest driver for that printer that you've managed to find?

As I said, its latest from the konica minolta (ie, manufacturer's) site - on this page. KONICA MINOLTA, Inc. Color and Black & White Laser Printers

I have also tried several others - all the same - ie, they work properly until reboot.

I'm trying to gauge whether the printer driver you're using is relatively recent, as in 2007 or 2008, or whether its only distinction is being the "latest for that printer", even if that means it's from 1989. If you can tell me the timestamp of the latest driver you've found and tested, that will help me (and others) to give you more useful advice.

Since you've tried multiple OSs and presumably multiple Vista and Win7 machines, the likelihood of machine-specific problems is obviously greatly diminished, and the driver becomes just about the only common factor.

Have you seen reports of others successfully using the very same build of the driver with Vista and/or Win7?

From that page I linked, its badged as Windows Vista (32 bit), Printer Driver, Version 1.5.2413.0 Date: 08-Mar-07

As I also said at the top, I've found various people with the same problem, but nobody who has a solution yet, so no I have seen no reports of others successfully using the same (or any other) driver with Vista.

Alright. Have you ever used a packet sniffer to generate a trace of network activity?

www.wireshark.org, download, install, start capture on Vista's NIC interface which would connect it to the printer. Repro the "several minutes" delay when trying to print. Stop and save the wireshark capture.

If you know how to analyse the capture yourself, you'd want to be checking whether an initial connection is made immediately as soon as the user tries to print, or whether there's literally nothing from Vista to the printer until the last few seconds when all of the activity takes place.

The capture may also reveal some sort of "retry" or error-handling behaviour which may help to explain what is happening at a network layer.

There is an immediate initial connection (consisting of 5 messages in wireshark). Then there is a delay of 180 seconds, then it tries again. I ran the same trace on XP machine & it just does everything first time. I'm not a network packet expert, but looking at the initial connection, on the Vista machine there's a TCP packet from the PC to the printer that includes [TCP CHECKSUM INCORRECT] during the first 'attempt':-

3 0.000228 192.168.123.5 192.168.123.195 TCP 49428 > hp-pdl-datastr [SYN] Seq=0 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=2

The second 'attempt' and many subsequent attempts (no delays in retrying) also show this error, but the page prints. All the TCP packets from the PC to the printer have this message, but not the ones from the printer to the PC. None of XP packets have this error message.

So presumably the process has a 3 minute initial 'try again' policy if there's a problem? But why does it actually work on retry, if the same error in all the messages?

Towards the end of the sequence 3 SMPP packets:-

160 180.898479 192.168.123.5 192.168.123.195 SMPP SMPP Unbind
164 180.898924 192.168.123.5 192.168.123.195 SMPP SMPP Query_sm[Unreassembled Packet [incorrect TCP checksum]]
170 180.902299 192.168.123.5 192.168.123.195 SMPP SMPP Bind_receiver[Unreassembled Packet [incorrect TCP checksum]]

I can post all the entries if necessary - just wondering if its actually going to help find out what's causing the problem.

Thanks for the help so far.

Don't worry about the "TCP checksum incorrect" business. That's just a side-effect of a mechanism called "checksum offload" whereby the NIC hardware itself is tasked with correcting/writing the packet checksum as the packet is leaving. Because wireshark inspects the packet (which is about to leave) before the NIC does its checksum calculations, it believes the data it finds in the checksum field is incorrect. That's not the problem and you can safely ignore that error message.

You're far more of a "network packet expert" than you think you are though

I don't know whether the answer is in that trace, but I'm completely sure that the initial connection attempt is different to the one which eventually ends up successfully printing, and it might be useful to look at those differences more closely. Can you paste more of that capture or just upload it? As long as you dont print anything confidential, its unlikely to contain sensitive info.

I've uploaded the output zipped up

Hmm, there is actually only one attempt, and it takes place 180sec after the TCP session is established. In other words, it's not retrying. All that happens initially is a perfectly normal TCP 3-way handshake. The session then sits idle for precisely 3 minutes before the printing starts and finishes within a tenth of a second.

This is a timeout of some sort. The printing process on the Vista client is presumably waiting 3 minutes for some condition or some set of events to come true, and it's willing to wait for up to 3 minutes.

How "tricked out" are those Vista/Win7 machines? Do they run AV, anti-malware, 3rd-party firewalls? It's possible that the 3min timeout is being caused by those types of utilities.

To understand what's being waited on without lots of trial-and-error, we'd have to debug the spooler and look at what it's doing during the 3min interval. Do you want to try that?

the vista/win7 machines have free AVG only - otherwise just windows built in stuff (firewall & defender) - same as XP machines... Also there's the 'it works normally when first installed before first reboot' fact. And I have tried it before installing anything else - same result.

How do we debug the spooler?

Do this on an x86 box. It's simpler in several ways.

1) Download and install the "Debugging Tools" package: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#a

2) From the folder where you installed it, run WinDBG.exe as admin (right-click, "run as admin...").

3) Press F6, sort "by executable", find SPOOLSV.EXE, select, OK.

4) It'll spew out a whole bunch of numbers and eventually dump you on a prompt at the bottom of the page. Just type G and press enter. This attaches the debugger to the spooler but then lets the spooler "Go" and continue to do its thang.

5) Start a print job which you expect will take 3min to complete.

6) About half-way into the 180sec wait, give focus to WinDBG and press ctrl+break on the keyboard or that "break" button on the WinDBG toolbar. This will cause the debugger to "break into" the spooler process and suspend all its actions.

7) Ignore all the spew again and wait for the prompt, then type this:

.dump /m spool1.dmp

If you don't give it a full path, the spool1.dmp file will be created in the same folder where you installed the debugger package. If that file is small enough when zipped up for you to upload it here, I might be able to tell you why the spooler is waiting.

Here's the file

MLMON__B.DLL, which is presumably some sort of port MONitor, is polling for an object every second, then going back to sleep for a second, then polling... and it looks like it doesn't give up until 180sec later.

Here's the stack of the spooler thread that's causing your delay:

0:016> kv
ChildEBP RetAddr Args to Child
0406c45c 777183b4 76b1c350 00000000 0406c4a4 ntdll!KiFastSystemCallRet
0406c460 76b1c350 00000000 0406c4a4 dfad41a5 ntdll!NtDelayExecution+0xc
0406c4c8 76ad1c7a 000003e8 00000000 0406c4ec kernel32!SleepEx+0x62 (FPO: [SEH])
0406c4d8 100013a2 000003e8 0000005a 00000000 kernel32!Sleep+0xf (FPO: [1,0,0])
0406c4ec 1000111d 004e2ad0 0000000e 0406c514 MLMON__B+0x13a2
0406e52c 10005175 024180a0 004e2ad0 47002661 MLMON__B+0x111d
0406e7d4 68144922 004e2ad0 024180a0 00000004 MLMON__B+0x5175
0406ec2c 68144b89 02422360 00000001 0406ecd8 localspl!PrintingDirectlyToPort+0x24e
0406ec54 7338ac49 02422360 00000001 0406ecd8 localspl!SplStartDocPrinter+0x5e
0406ec68 7338ac87 02416328 00000001 0406ecd8 spoolss!StartDocPrinterWorkerW+0x23
0406ec84 016f1f83 02416328 00000001 0406ecd8 spoolss!StartDocPrinterW+0x32
0406f8a0 68153793 024199f0 0406f8c8 00000000 MIMFPR_B+0x1f83
0406ff10 76b14911 024199f0 0406ff5c 776fe4b6 localspl!PortThread+0x2c4 (FPO: [1,405,4])
0406ff1c 776fe4b6 024199f0 737ec941 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
0406ff5c 776fe489 681534cf 024199f0 00000000 ntdll!__RtlUserThreadStart+0x23 (FPO: [SEH])
0406ff74 00000000 681534cf 024199f0 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

0:016> ?3e8
Evaluate expression: 1000 = 000003e8 <<< It invokes a 1000 millisecond sleep in a polling loop

Image path: C:\Windows\System32\MLMON__B.DLL
Image name: MLMON__B.DLL
Timestamp: Wed Dec 06 13:06:45 2006 (457625B5)10000000 10017000 MLMON__B

I can't tell precisely what it's waiting for from a minidump (that info doesn't fit into the 80KB!), but it doesn't really matter because I probably can't offer any practical way to prevent its actions. I'd suggest:

- Updating that port monitor. It's older than the rest of the (2007) package.
- If you can't update it, remove it. That might impact printer functionality though.
- If you can't do any of that, send the same dump to K-M and ask them to tell you why their port monitor is making you wait 180sec every time before printing.

Muchos gracias!

Removing mlmon_b.dll seems to have done the trick - no apparent loss of functionality so far. Had to remove it from outside vista as wouldn't allow me inside (I did also try editing the driver inf file to remove all references to the mlmon_b.dll file & reinstalling, but that failed).

I had already emailed K-M (with a general question about the delay), but no reply yet, and not holding my breath (and if there was an updated monitor dll file I presume it would have to come from them). I will just send another letting them know what is causing the problem.

Again, many thanks - I seem to be fully functional.

Glad to hear it's working without the 3min delay now.

That port monitor presumably did do something, so I'd suggest being on the lookout for missing printer functionality in the future. (Cue the William Shatner scene out of Airplane 2 - "These red lights keep moving back and forth, but aside from that this thing seems to have no other function whatsoever" )

Did you guys get an answer from K-M or do you any further information about the problem ? I'm experiencing that problem since I moved from XP to Vista (changing PCs). What's weird is that whenever I reinstall the printer driver, it works fine until I reboot.
What happens with the MLMON_B.DLL file once the PC is rebooted ?

phil3821 said:

Did you guys get an answer from K-M or do you any further information about the problem ? I'm experiencing that problem since I moved from XP to Vista (changing PCs). What's weird is that whenever I reinstall the printer driver, it works fine until I reboot.
What happens with the MLMON_B.DLL file once the PC is rebooted ?

Click to expand...

There's no way to answer your question accurately without either being a K-M developer or doing a lot of debugging. Anyway, it seems like a commonly experienced issue with that bundle of drivers. The OP didn't seem to experience any negative side-effects from removing the DLL in question, so you might want to test the same workaround.

For authoritative answers, you should contact K-M. It's their code that's slowing things down for 3 minutes per print. They ought to know why.

I have my printer set up via USB on a Windows 7 x64. I found that deselecting 'Enable bidirectional support' in 'Printer properties' -> 'Ports' solved the problem of slow printing. I think it might have the same effect as removing the monitor .dll file as suggested elsewhere.

edevita said:

I have my printer set up via USB on a Windows 7 x64. I found that deselecting 'Enable bidirectional support' in 'Printer properties' -> 'Ports' solved the problem of slow printing. I think it might have the same effect as removing the monitor .dll file as suggested elsewhere.

Click to expand...

After looking around for two days and spending over an hour with KM tech support, I found edevita's solution of "deselecting 'Enable bidirectional support' in 'Printer properties' -> 'Ports' " works GREAT! It would take exactly 3 minutes before the printer would print from my VISTA laptop but printing would start immediately from my wife's XP laptop (both over wireless to router connection).
Thanks so much edevita.