Not Too Sharp

[billroper]

So we've got a problem where our program crashes when printing to a nice, shiny, new Sharp Color Copier/Printer. Of course, we don't own one of these beasties and since they cost about $25,000 (if I'm reading the right website), we're not likely to. But without being able to see what's going on, this is a classic black box problem.

Bright boy that I am, I come up with a solution: if I can VPN into the client site and connect to their printer, I can try to replicate the bug in the debugger. After many trials and tribulations, the client sets up the VPN and I can't connect.

Our firewall won't let me out.

One trip to Office Depot later, I (ok, my company) am the proud owner of a brand-new USB 2.0 external modem. Which allows me to dial up an ISP using a borrowed account and VPN into his network.

Where the printer doesn't want to talk to me. Eventually, we convince the printer that it wants to let me connect to it. (This connectivity comes and goes, seemingly at random. It's a mystery.)

The debugger reports that various Sharp-related DLLs are gleefully loading and unloading (for no known reason -- I understand loading the DLL, but I don't understand unloading it and then reloading it again. Who programmed these drivers?). But everything appears to be working fine until the MSCMS.DLL loads, which is shortly followed by a crash, deep in the bowels of the Sharp drivers.

MSCMS.DLL (so Google tells me) is apparently the Microsoft Color Management System DLL. And some of the reports suggest that it's just a wee bit touchy. Or is subject to incompatibilities, depending on what version of the DLL you're using.

But the box is no longer black. It's more like obsidian -- translucent, but still opaque.

Comments

[mplsfish.livejournal.com]

Well written. I not only understood much of it, I read it all. Computer is not my kind of geek. You are a translator.

[kevinnickerson.livejournal.com]

Well you see, you unload and reload dll's when they're buggy and have a horrible leak.

Don't laugh, we have code that stops and restarts processes for that reason. When you can't fix the vendor's code, and they won't, you resort to really stupid things.

OK, that's probably not your problem.

[tigertoy.livejournal.com]

The process of printing in an MFC app is one of the worst morasses of gaggage I've ever wandered into, and I remind you that I was a PLATO sysprog, so I know gaggage when I see it. It would not surprise me if it is loading the DLLs early in the process as part of getting printer capabilities to set the parameters, through a series of calls that have been modularized to the point they don't understand their own context and hence unload the DLLs again, and then when you actually try to print it has to load them again.

When you have to go out and buy a modem to get around your own firewall, something is wrong with your company.

My final observation is that unless you get lucky and find this quickly, the contortions you're going through to do it remotely are probably going to be more expensive than renting one of the Sharp machines for a bit. Of course, that's assuming your company actually understands that your time is valuable, a concept that eludes some companies I've worked for. "I can pay you to bang your head against this problem for a month, but I don't have a budget to spend $500 to solve it tomorrow."