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?