• Hail Guest!
    We're looking for Community Content Contribuitors to Stratics. If you would like to write articles, fan fiction, do guild or shard event recaps, it's simple. Find out how in this thread: Community Contributions
  • Greetings Guest, Having Login Issues? Check this thread!
  • Hail Guest!,
    Please take a moment to read this post reminding you all of the importance of Account Security.
  • Hail Guest!
    Please read the new announcement concerning the upcoming addition to Stratics. You can find the announcement Here!

OT: Monitoring COM calls? -Printing to wrong printers in corporate environment

Wulf2k

Stratics Legend
Stratics Veteran
Stratics Legend
Long story leading to my question, feel free to ignore:

At the end of each month the assistants where I work start printing out bills to send out all at once, and inevitably a few of them go to the wrong printer.

The program is Aderant CMS. They can select 60 bills at once, tell them to print to their printer (same click prints all 60, they're not selecting the printer multiple times) and 55 can print at theirs, 3 at the person's beside them, 2 somewhere else, and they get 4 others that other people were trying to print.

This only happens when there's a high volume of bill printing through this one program. Printing of docs/pdfs/whatever is never affected. The print server's event viewer shows each print job going to wherever it printed out, so the print jobs are getting mixed up before reaching the print server.

The billing program runs on a server, they connect to it via web browser. The server then uses COM to load Word and print the bills individually.

So, my question: Does anybody know how to monitor/log/whatever COM calls to figure out why the print jobs are mixing up? The program vendor claims it doesn't happen to anybody else, so must be a problem with our environment or Microsoft Word.

I need some way to show that Word is getting those COM calls telling it to print to the wrong printer, and it's not a problem somewhere else.

Any input would be appreciated.
 

RawHeadRex

Slightly Crazed
Stratics Veteran
Stratics Legend
goodness gracious lol
For the vendor to claim it doesn't happen to others is highly suspect imho, at the very least they would have seen this before and have some sort of answer besides it's your fault (admin issue). sounds like some sort of spill over from the print spooler memory on the server but you're saying it happens before it reaches the server. are they assigned more than one printer per user? what type of network are you running ?
 

Wulf2k

Stratics Legend
Stratics Veteran
Stratics Legend
Thanks for the link Skylark. It looked like it should have done exactly what I wanted, only... It doesn't.

If I attach it to the billing server executable, it stops jobs from printing. If I attach it to Word, it shows some stuff that looks to me like it only deals with the GUI, and nothing about printing, but it's a little too machine-codey to be sure.

Rawhead, we are not pleased with the vendor, to put it nicely. There've been nothing but problems for the 7+ years the software's been used, but at this point everything revolves around it.

Each user has a single printer at their desk, but they're all network printers and selected from a list. The print server's running 2003 SP2. All in an AD environment, but I don't see the specifics of that mattering to the question at hand. Lemme know if you want any more information.
 

Skylark SP

Available Storage: 0
Stratics Veteran
Stratics Legend
Thanks for the link Skylark. It looked like it should have done exactly what I wanted, only... It doesn't.

If I attach it to the billing server executable, it stops jobs from printing. If I attach it to Word, it shows some stuff that looks to me like it only deals with the GUI, and nothing about printing, but it's a little too machine-codey to be sure.
Bummer...that is the only utility I found that purported to actually log COM calls. There are utilities meant for debugging, but they largely deal with feeding input to let programmers see what can break the app, I haven't seen any tools that looked as if they would let you simply log the calls while the code is running in a production environment, although perhaps they can be adapted to do so. This is way out of my area of experience - perhaps someone versed in software Q/A and program debugging might be able to point you in the right direction. :(

-Skylark
 

Harlequin

Babbling Loonie
Stratics Veteran
Stratics Legend
The vendor's program is definitely mixing up the ports it's printing to. You mentioned that you want to show that Word is sending the jobs to the com ports, does the vendor's program interface with Word to print the docs?

Maybe due to the volume, it's not waiting for a previous session of Word to close properly before printing the next. If that happens, it is likely that word still thinks the program wants to print to the previous printer.

Are the printers have their own printer queues defined right? Maybe this will be sufficient for your requirements - Instead of tracing traffic to COM ports, go to each print queue's properties -> advanced -> and enable "Keep printed documents".

This way you have an audit trail of which jobs went to which printer that you can show the vendor. If the names of the print jobs isn't descriptive enough to show you which is which, you can reprint them to verify.
 

Wulf2k

Stratics Legend
Stratics Veteran
Stratics Legend
The vendor's program is definitely mixing up the ports it's printing to. You mentioned that you want to show that Word is sending the jobs to the com ports, does the vendor's program interface with Word to print the docs?
Yes, the program uses Word to print. It's not so much that I want to prove Word is sending jobs to the wrong printers, we know this for a fact. What I want to prove is that the vendor program is already wrong when it tells Word the printer to print to.

Maybe due to the volume, it's not waiting for a previous session of Word to close properly before printing the next. If that happens, it is likely that word still thinks the program wants to print to the previous printer.
That's one thing we considered, but there's no logic to where the jobs will print out. Random, unused network printers will print out the occasional job.

Are the printers have their own printer queues defined right? Maybe this will be sufficient for your requirements - Instead of tracing traffic to COM ports, go to each print queue's properties -> advanced -> and enable "Keep printed documents".
We can already more or less check this with the event viewer. The printer that prints the job is the one that was 'told' to print the job, it was just told incorrectly. We need to find out if the program had the error and Word just printed where it was told to print, or if the program sent out the job correctly, and it got messed up in Word somehow.

This way you have an audit trail of which jobs went to which printer that you can show the vendor. If the names of the print jobs isn't descriptive enough to show you which is which, you can reprint them to verify.
Just to clarify, I don't want to trace traffic on COM ports (eg, COM 1 through 4, etc), I want to log this sort of COM communication.
 
Top